Glossary OS

Plain meaning

Start with the shortest useful explanation before going deeper.

A nullifier is a cryptographic value derived deterministically from a compressed account's leaf hash (and optionally a secret) that is published and recorded on-chain when that compressed account is consumed (spent) in a state transition, permanently marking the account as used and preventing it from being spent a second time in a double-spend attack. In Light Protocol, nullifiers are inserted into an on-chain nullifier queue account and periodically batch-processed by Forester nodes into a nullifier set stored in a separate Merkle tree, allowing the validity proof to assert both that the input account exists (inclusion proof) and that its nullifier has not yet been recorded (non-membership proof). The nullifier scheme allows compressed accounts to be treated as UTXOs — each account is consumed once and replaced by one or more output accounts — while maintaining the privacy and succinctness properties of the ZK proof system.

Mental model

Use the quick analogy first so the term is easier to reason about when you meet it in code, docs, or prompts.

Think of it as a building block that connects one definition to the larger Solana system around it.

Technical context

Place the term inside its Solana layer so the definition is easier to reason about.

Compressed state, proofs, and scale-oriented storage patterns.

Why builders care

Turn the term from vocabulary into something operational for product and engineering work.

This term unlocks adjacent concepts quickly, so it works best when you treat it as a junction instead of an isolated definition.

AI handoff

Use this compact block when you want to give an agent or assistant grounded context without dumping the entire page.

Nullifier (nullifier)
Category: ZK Compression
Definition: A nullifier is a cryptographic value derived deterministically from a compressed account's leaf hash (and optionally a secret) that is published and recorded on-chain when that compressed account is consumed (spent) in a state transition, permanently marking the account as used and preventing it from being spent a second time in a double-spend attack. In Light Protocol, nullifiers are inserted into an on-chain nullifier queue account and periodically batch-processed by Forester nodes into a nullifier set stored in a separate Merkle tree, allowing the validity proof to assert both that the input account exists (inclusion proof) and that its nullifier has not yet been recorded (non-membership proof). The nullifier scheme allows compressed accounts to be treated as UTXOs — each account is consumed once and replaced by one or more output accounts — while maintaining the privacy and succinctness properties of the ZK proof system.
Related: Zero-Knowledge Proofs (ZKP), Compressed Account

Glossary Copilot

Ask grounded Solana questions without leaving the glossary.

Use glossary context, relationships, mental models, and builder paths to get structured answers instead of generic chat output.

Open full Copilot workspace

Question

Explain this code

Optional: paste Anchor, Solana, or Rust code so the Copilot can map primitives back to glossary terms.

Ask a glossary-grounded question

The Copilot will answer using the current term, related concepts, mental models, and the surrounding glossary graph.

Concept graph

See the term as part of a network, not a dead-end definition.

These branches show which concepts this term touches directly and what sits one layer beyond them.

Branch

Zero-Knowledge Proofs (ZKP)

A zero-knowledge proof is a cryptographic protocol by which a prover convinces a verifier that a statement is true — for example, that a state transition is valid — without revealing any information beyond the truth of the statement itself, satisfying the properties of completeness, soundness, and zero-knowledge. In Solana's ecosystem, ZKPs are used by ZK Compression (via Groth16 SNARKs) to prove correct state transitions for compressed accounts without storing full account state on-chain, and by the Token-2022 Confidential Transfers extension (via ElGamal encryption and range proofs) to prove token balances are non-negative without revealing the actual amounts. Solana's BPF VM exposes the alt_bn128 elliptic curve syscall to make on-chain Groth16 proof verification computationally feasible within the 1.4M compute unit budget.

Groth16 PLONK

Open term

Branch

Compressed Account

A compressed account is a Solana account whose state is stored as a leaf in an on-chain Concurrent Merkle Tree rather than as a dedicated on-chain account, making it 100–1,000x cheaper to create and maintain because no rent-exempt lamport balance is required per account. Compressed accounts are identified by a hash of their data and position in the tree; to interact with one, a client must supply a Merkle proof (or rely on the canopy) showing the leaf is part of the current tree root, which the on-chain program verifies before processing the state change. Light Protocol's compressed account model supports arbitrary data, discriminators, and owner programs, making it a general-purpose replacement for expensive on-chain accounts in high-volume use cases.

ZK Compression State Compression

Open term

Next concepts to explore

Keep the learning chain moving instead of stopping at one definition.

These are the next concepts worth opening if you want this term to make more sense inside a real Solana workflow.

ZK Compression

Zero-Knowledge Proofs (ZKP)

A zero-knowledge proof is a cryptographic protocol by which a prover convinces a verifier that a statement is true — for example, that a state transition is valid — without revealing any information beyond the truth of the statement itself, satisfying the properties of completeness, soundness, and zero-knowledge. In Solana's ecosystem, ZKPs are used by ZK Compression (via Groth16 SNARKs) to prove correct state transitions for compressed accounts without storing full account state on-chain, and by the Token-2022 Confidential Transfers extension (via ElGamal encryption and range proofs) to prove token balances are non-negative without revealing the actual amounts. Solana's BPF VM exposes the alt_bn128 elliptic curve syscall to make on-chain Groth16 proof verification computationally feasible within the 1.4M compute unit budget.

Open term

ZK Compression

Compressed Account

A compressed account is a Solana account whose state is stored as a leaf in an on-chain Concurrent Merkle Tree rather than as a dedicated on-chain account, making it 100–1,000x cheaper to create and maintain because no rent-exempt lamport balance is required per account. Compressed accounts are identified by a hash of their data and position in the tree; to interact with one, a client must supply a Merkle proof (or rely on the canopy) showing the leaf is part of the current tree root, which the on-chain program verifies before processing the state change. Light Protocol's compressed account model supports arbitrary data, discriminators, and owner programs, making it a general-purpose replacement for expensive on-chain accounts in high-volume use cases.

Open term

ZK Compression

Photon Indexer

Photon is Light Protocol's open-source indexer service that continuously reads Solana's transaction logs and ledger to reconstruct the full state of compressed accounts and Concurrent Merkle Trees, making this off-chain data queryable via a JSON-RPC API that mirrors the standard Solana RPC interface with additional ZK-compression-specific methods. Because compressed account data is not stored in on-chain account space but is instead emitted during transactions as instruction data and logs, a dedicated indexer like Photon is required for clients to fetch account state, generate Merkle proofs, and construct valid transactions that interact with compressed accounts. Photon exposes methods such as getCompressedAccount, getCompressedTokenAccountsByOwner, and getValidityProof, and Light Protocol operates a hosted Photon endpoint while teams can also self-host it against their own RPC node.

Open term

ZK Compression

Merkle Tree

A Merkle tree is a binary hash tree in which every leaf node contains a cryptographic hash of a data block, and every non-leaf (internal) node contains the hash of its two children, such that the single root hash cryptographically commits to the entire dataset and any modification to any leaf produces a detectably different root. In Solana, Merkle trees underpin state compression: the SPL Account Compression program maintains Concurrent Merkle Trees on-chain with only the root hash persisted in account storage, while all leaf data is derivable from transaction logs. The Poseidon hash function is preferred over SHA-256 for ZK-friendly Merkle trees because it is algebraically efficient inside arithmetic circuits used for zero-knowledge proof generation.

Open term

Related terms

Follow the concepts that give this term its actual context.

Glossary entries become useful when they are connected. These links are the shortest path to adjacent ideas.

ZK Compressionzk-proofs

Zero-Knowledge Proofs (ZKP)

A zero-knowledge proof is a cryptographic protocol by which a prover convinces a verifier that a statement is true — for example, that a state transition is valid — without revealing any information beyond the truth of the statement itself, satisfying the properties of completeness, soundness, and zero-knowledge. In Solana's ecosystem, ZKPs are used by ZK Compression (via Groth16 SNARKs) to prove correct state transitions for compressed accounts without storing full account state on-chain, and by the Token-2022 Confidential Transfers extension (via ElGamal encryption and range proofs) to prove token balances are non-negative without revealing the actual amounts. Solana's BPF VM exposes the alt_bn128 elliptic curve syscall to make on-chain Groth16 proof verification computationally feasible within the 1.4M compute unit budget.

Open term

ZK Compressioncompressed-account

Compressed Account

A compressed account is a Solana account whose state is stored as a leaf in an on-chain Concurrent Merkle Tree rather than as a dedicated on-chain account, making it 100–1,000x cheaper to create and maintain because no rent-exempt lamport balance is required per account. Compressed accounts are identified by a hash of their data and position in the tree; to interact with one, a client must supply a Merkle proof (or rely on the canopy) showing the leaf is part of the current tree root, which the on-chain program verifies before processing the state change. Light Protocol's compressed account model supports arbitrary data, discriminators, and owner programs, making it a general-purpose replacement for expensive on-chain accounts in high-volume use cases.

Open term

Stay in the same layer and keep building context.

These entries live beside the current term and help the page feel like part of a larger knowledge graph instead of a dead end.

ZK Compression

State Compression

State Compression is Solana's technique for storing the cryptographic fingerprint (root hash) of a Merkle tree on-chain while keeping the actual leaf data off-chain in the Solana ledger's account data logs, reducing the cost of storing large datasets by orders of magnitude. A compressed NFT collection of 1 million items costs roughly 50 SOL to mint versus ~12,000 SOL with standard SPL accounts, because only a single Concurrent Merkle Tree account occupies on-chain storage. Any data change requires updating the root hash and supplying a Merkle proof to the on-chain program, which verifies inclusion without reading the full dataset.

Open term

ZK Compression

ZK Compression, pioneered by Light Protocol, extends Solana's state compression model beyond NFTs to general-purpose compressed accounts by using zero-knowledge proofs (specifically Groth16 SNARKs verified via the alt_bn128 syscall) to prove the validity of state transitions without storing full account state on-chain. Compressed accounts live in on-chain Merkle trees but their data is reconstructed from the Solana ledger by indexers like Photon, enabling developers to build applications that use thousands of accounts at a fraction of the normal rent cost — often 1,000x to 5,000x cheaper than regular accounts. The protocol introduces compressed tokens, compressed PDAs, and a system of nullifiers to prevent double-spends while maintaining Solana's throughput.

Open term

ZK Compression

Compressed Account

A compressed account is a Solana account whose state is stored as a leaf in an on-chain Concurrent Merkle Tree rather than as a dedicated on-chain account, making it 100–1,000x cheaper to create and maintain because no rent-exempt lamport balance is required per account. Compressed accounts are identified by a hash of their data and position in the tree; to interact with one, a client must supply a Merkle proof (or rely on the canopy) showing the leaf is part of the current tree root, which the on-chain program verifies before processing the state change. Light Protocol's compressed account model supports arbitrary data, discriminators, and owner programs, making it a general-purpose replacement for expensive on-chain accounts in high-volume use cases.

Open term

ZK Compression

Concurrent Merkle Tree

A Concurrent Merkle Tree (CMT) is a specialized on-chain Solana data structure that allows multiple state updates to the same Merkle tree within a single block without conflicting, by recording a changelog buffer of recent root transitions that validators use to reconcile parallel proof submissions. A CMT is parameterized by its maximum depth (max_depth, determining tree capacity of 2^max_depth leaves), max_buffer_size (number of concurrent changes the changelog can track, directly controlling how many operations per slot the tree can safely absorb), and an optional canopy_depth. The SPL Account Compression program manages CMTs, and they are the foundational storage primitive for both Metaplex compressed NFTs and Light Protocol compressed accounts.

Open term