The Compressed Token Program extends existing Solana token standards with light-mints, light-tokens and compressed tokens.

	Account Type	Key Features
Light-Mint	Compressed account	Rent-free mint accounts (similar to SPL mints) Custom Token Metadata extension
Light-Token	Solana account	Store tokens of light-mints, SPL mints, or Token 2022 mints Sponsored rent exemption via compressible extension Use for active token accounts with frequent writes (trading, etc.)
Compressed Token	Compressed account	Compressed account with `TokenData` field Rent-free and SPL-compatible Use for storage of inactive tokens and token distribution Light-token accounts are automatically compressed/decompressed when active/inactive.

Light-Mint Accounts

Light-mints are compressed accounts and cannot be decompressed.
SPL mints can not be compressed to light-mints.

Light-mints uniquely represent a token on Solana and store its global metadata, similar to SPL mint accounts with few core differences:

Light-mint accounts are rent-free.
Tokens created from light-mints are light-tokens.
Token metadata (name, symbol, URI) is stored as an extension in the struct.

Diagram
Source Code

Diagram showing light-mint compressed account structure with three components: Hash (identifier for light-mint in purple box), Account (struct containing BaseMint with SPL-compatible fields, light-mint Data for program state, and optional Extensions for Token Metadata), and BasemintData (containing Supply, Decimals, Mint Authority, and Freeze Authority fields) with Token Metadata extension

pub struct CompressedMint {
    // SPL mint layout
    pub base: BaseMint,
    // light-mint state used by the Compressed Token Program
    pub metadata: CompressedMintMetadata
    // Field for Token Metadata extension
    pub extensions: Option<Vec<ExtensionStruct>>,
}

Find the source code of light-mints here.

The metadata field is used by the Compressed Token Program to store the internal state of a light-mint. The BaseMint field replicates the field layout and serialization format of SPL Mint accounts. The struct is serialized with Borsh to match the on-chain format of SPL tokens and mints. Here is how light-mints and SPL mints compare:

Basemint vs SPL mint
BaseMint Struct

Field	Light-Mint	SPL Mint
mint_authority	✓	✓
supply	✓	✓
decimals	✓	✓
is_initialized	✓	✓
freeze_authority	✓	✓
Light-Mint Data	✓	-
Extensions	✓	via Token-2022

pub struct BaseMint {
    /// Optional authority used to mint new tokens. The mint authority may only
    /// be provided during mint creation. If no mint authority is present
    /// then the mint has a fixed supply and no further tokens may be
    /// minted.
    pub mint_authority: Option<Pubkey>,
    /// Total supply of tokens.
    pub supply: u64,
    /// Number of base 10 digits to the right of the decimal place.
    pub decimals: u8,
    /// Is initialized - for SPL compatibility
    pub is_initialized: bool,
    /// Optional authority to freeze token accounts.
    pub freeze_authority: Option<Pubkey>,
}

Light-Token Account

Light-token accounts are Solana accounts, not compressed accounts.

A light-token account holds token balances like SPL Token accounts:

A wallet needs a light-token account for each light-mint, SPL mint, or Token 2022 mint it wants to hold, with the wallet address set as the light-token account owner.
Each wallet can own multiple light-token accounts for the same light-mint.
A light-token account can only have one owner and hold units of one light-mint.

Diagram
Source Code

Diagram showing light-token Solana account structure with three components: Address (identifier for light-token account in purple box), Account (struct containing Data bytes, Executable flag, Lamports balance, and Owner set to Compressed Token Program), and AccountData (containing Mint, Owner, Amount, and Extensions fields)

/// Ctoken account structure (with extensions).
pub struct CToken {
    pub mint: Pubkey,
    pub owner: Pubkey,
    pub amount: u64,
    pub delegate: Option<Pubkey>, // instruction not implemented yet
    pub state: u8,
    pub is_native: Option<u64>,
    pub delegated_amount: u64, // instruction not implemented yet
    pub close_authority: Option<Pubkey>,
    pub extensions: Option<Vec<ExtensionStruct>>, // Optional extensions e.g. compressible
}

Find the source code of light-tokens here.

Light-token accounts replicate the field layout and serialization format of SPL Token accounts. The struct is serialized with Borsh to match the on-chain format of SPL tokens. Here is how light-tokens and SPL tokens compare:

Field	Light-Token	SPL Token Account
mint	✓	✓
owner	✓	✓
amount	✓	✓
delegate	unimplemented	✓
state	✓	✓
is_native	✓	✓
delegated_amount	unimplemented	✓
close_authority	✓	✓
extensions	✓	via Token-2022

Rent Config for Light-Tokens

The rent-exemption for light-token account creation is sponsored by Light Protocol.
Transaction payer’s pay rent
to keep accounts “active”.
“Inactive” accounts, where rent is below one epoch, are compressed
and the rent-exemption can be claimed by the rent sponsor.
Transfers to inactive accounts (decompress).

This way rent is automatically paid when accounts are used:

Event	Total Cost	Payer	Time of Rent funded
Account Creation		Transaction payer	Funds 24h rent
Automatic Top ups (when rent < 3h)	776 lamports	Transaction payer	Funds 3h rent
Load Account (when inactive)		Transaction payer	Funds 24h rent

We recommend to use default values, but you can customize prepaid rent and top ups:

Associated Light-Token Account

Associated light-token accounts (light-ATAs) follow the same pattern as associated token accounts (ATA):

Each wallet needs its own light-token account to hold tokens from the same light-mint.
The address for light-ATAs is deterministically derived with the owner’s address, light-token program ID, and mint address.

let seeds = [
    owner.as_ref(),          // Wallet address (32 bytes)
    program_id.as_ref(),     // Compressed Token Program ID (32 bytes)
    mint.as_ref(),           // light-mint address (32 bytes)
    bump.as_ref(),           // Bump seed (1 byte)
];

Find the source code to associated light-token accounts here.

Compressed Token Account

Compressed token accounts store token balance, owner, and other information like SPL and light-tokens. Any light-token or SPL token can be compressed/decompressed at will. We recommend to use compressed tokens for token distribution or storage of inactive tokens.

Light-token accounts with the compressible extension are automatically compressed with no writes in 27,000 slots (3h) and decompressed with new writes.

Diagram
Source Code

Diagram showing compressed token account structure with three components: Hash (identifier for compressed token account in purple box), Account (struct containing Data bytes, Executable flag, Lamports balance, and Address set to None), and AccountData (containing Mint, Owner, Amount, and Extensions fields marked as unimplemented)

pub struct TokenData {
    pub mint: Pubkey,
    pub owner: Pubkey,
    pub amount: u64,
    pub delegate: Option<Pubkey>,
    pub state: u8,
    /// Placeholder for TokenExtension tlv data (unimplemented)
    pub tlv: Option<Vec<u8>>,
}

Light-Token Standard (Beta)

Get Started with ZK Compression

Compressed Tokens

Compressed PDAs

JSON RPC Methods

Learn

Resources

References

SDK Reference

Light-Token Standard

Light-Mint Accounts

Light-Token Account

Rent Config for Light-Tokens

Associated Light-Token Account

Compressed Token Account

Next Steps

Create Light-Token Accounts

Light-Token Standard (Beta)

Get Started with ZK Compression

Compressed Tokens

Compressed PDAs

JSON RPC Methods

Learn

Resources

References

SDK Reference

​Light-Mint Accounts

​Light-Token Account

​Rent Config for Light-Tokens

​Associated Light-Token Account

​Compressed Token Account

​Next Steps

Create Light-Token Accounts

Light-Mint Accounts

Light-Token Account

Rent Config for Light-Tokens

Associated Light-Token Account

Compressed Token Account

Next Steps