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 and transaction fees while the user only signs to authorize the transfer.
const ix = createLightTokenTransferInstruction(
  senderAta,
  recipientAta,
  sender.publicKey,
  amount,
  sponsor.publicKey, // sponsor pays rent top-ups and transaction fees
);

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

Gasless transactions 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 live on Solana mainnet. Start integrating with the Quickstart and Toolkits.For token distribution use cases (airdrops, claims), see Compressed Tokens, supported by leading wallets such as Phantom and Backpack.
No. The light-token-sdk methods are a superset of the SPL-token API — every SPL operation (transfer, approve, revoke, freeze, thaw, burn, close) plus unified balance aggregation, automatic load/decompress, wrap/unwrap, and cross-program dispatch. See “What does ‘superset of the SPL-token API’ mean?” below for details.
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.
The Light Token SDK covers every SPL Token operation and adds extra capabilities:
CategoryWhat it does
Cross-program dispatchInterface methods (e.g., transferInterface) auto-detect the token program and dispatch to SPL, Token 2022, or Light Token.
Unified balancegetAtaInterface returns a unified balance for a given mint, aggregating Light Token (hot + cold), SPL, and Token 2022 sources.
Wrap / UnwrapFor interoperability with applications that don’t support Light Token yet, you can wrap / unwrap SPL or Token 2022 tokens into Light Token associated token accounts and back.

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.
Light Token supports 16 Token-2022 extensions. Some have restrictions.
ExtensionRestrictionDescriptionLinks
MetadataPointer-Points a mint to the account that stores its metadata.Solana Docs · Example
TokenMetadata-Stores token name, symbol, and URI directly on the mint.Solana Docs · Example
TransferFeeConfigFees must be zeroWithholds a percentage of each transfer as a fee.Solana Docs · Example
TransferHookprogram_id must be nilInvokes a custom program on every transfer via CPI.Solana Docs · Example
InterestBearingConfig-Displays a UI-adjusted balance that accrues interest over time.Solana Docs · Example
DefaultAccountStateSet compression_only flag on token accountsSets the initial state (e.g., frozen) for newly created token accounts.Solana Docs · Example
PermanentDelegateSet compression_only flag on token accountsGrants an authority unrestricted transfer and burn rights over all accounts for the mint.Solana Docs · Example
MintCloseAuthoritySet compression_only flag on token accountsAllows a designated authority to close a mint account.Solana Docs · Example
GroupPointer-Points a mint to the account that stores group configuration.Solana Docs · Example
GroupMemberPointer-Points a mint to the account that stores group member configuration.Solana Docs · Example
TokenGroup-Stores group configuration directly on the mint (e.g., NFT collections).Solana Docs · Example
TokenGroupMember-Stores group member configuration directly on the mint.Solana Docs · Example
PausableSet compression_only flag on token accountsAllows an authority to pause all minting, burning, and transfers.Solana Docs · Example
ConfidentialTransferMintInitialized but not enabledConfigures auditor keys for confidential (encrypted) transfers.Solana Docs · Example
ConfidentialTransferFeeConfigInitialized but not enabledEncrypts withheld transfer fees under an auditor’s public key.Solana Docs
ConfidentialMintBurnInitialized but not enabledAllows minting and burning of tokens with encrypted amounts.Solana Docs

View all supported extensions

Additional extensions can be requested.
  • 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