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.
Account Creation CostLightStandard Solana
Mint account~0.00001 SOL~0.0015 SOL
Associated token account~0.00001 SOL~0.0029 SOL
PDA (100-byte)~0.0000115 SOL~0.0016 SOL
Rent-exemption: paid by a rent sponsor PDA.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). Set your application as the fee payer so users never interact with SOL.Hot-Cold Lifecycle of Accounts.Accounts get auto-compressed (cold balance) when the virtual rent balance goes below a threshold (eg 24h without write bump). The cold account’s state is cryptographically preserved on the Solana ledger. Users only interact with hot accounts and load the cold balance in-flight when using the account again.
Account lifecycle
Account lifecycle
Set the payer parameter to the sponsor’s public key on any Light Token instruction. The sponsor pays SOL for rent top-ups while the user only signs to authorize the transfer.
const ix = createLightTokenTransferInstruction(
  senderAta,
  recipientAta,
  sender.publicKey,
  amount,
  sponsor.publicKey, // sponsor pays rent top-ups
);

await sendAndConfirmTransaction(rpc, tx, [sponsor, sender]);

Sponsor rent top-ups guide

​
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 Cost
Light-TokenSPL-Token
Mint Account0.00001 SOL0.0015 SOL
Token Account0.00001 SOL0.0029 SOL
CU Performance
Light-TokenSPL-Token
ATA Creation4,34814,194
Transfer3124,645
Transfer (rent-free)1,8854,645
Yes! Light Token is deployed on devnet. You can 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()

View complete Solana to Light Reference

Side-by-side mapping of every Light Token instruction against its SPL/Solana equivalent.
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.
Regular PDALight-PDA
100-byte account~0.0016 SOL~0.0000115 SOL
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.
Regular PDACompressed PDA
100-byte account~0.0016 SOL~0.000015 SOL
Light-PDACompressed PDA
StorageOn-chain; auto-compresses when inactiveAlways compressed
Validity proofNot requiredRequired for every read and write
Program changesMinimal changes. Leaves program logic mostly untouched.Custom Logic
Best forShared state: DeFi pools, vaults, config, program-owned accountsPer-user state: profiles, credentials, DePIN nodes, nullifiers

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