Expand description

SPL Account Compression is an on-chain program that exposes an interface to manipulating SPL ConcurrentMerkleTrees

A buffer of proof-like changelogs is stored on-chain that allow multiple proof-based writes to succeed within the same slot. This is accomplished by fast-forwarding out-of-date (or possibly invalid) proofs based on information stored in the changelogs. See a copy of the whitepaper here

To circumvent proof size restrictions stemming from Solana transaction size restrictions, SPL Account Compression also provides the ability to cache the upper most leaves of the concurrent merkle tree. This is called the “canopy”, and is stored at the end of the ConcurrentMerkleTreeAccount. More information can be found in the initialization instruction documentation.

While SPL ConcurrentMerkleTrees can generically store arbitrary information, one exemplified use-case is the Bubblegum contract, which uses SPL-Compression to store encoded information about NFTs. The use of SPL-Compression within Bubblegum allows for:

  • up to 1 billion NFTs to be stored in a single account on-chain (>10,000x decrease in on-chain cost)
  • up to 2048 concurrent updates per slot

Operationally, SPL ConcurrentMerkleTrees must be supplemented by off-chain indexers to cache information about leafs and to power an API that can supply up-to-date proofs to allow updates to the tree. All modifications to SPL ConcurrentMerkleTrees are settled on the Solana ledger via instructions against the SPL Compression contract. A production-ready indexer (Plerkle) can be found in the Metaplex program library



  • An Anchor generated module, providing a set of structs mirroring the structs deriving Accounts, where each field is a Pubkey. This is useful for specifying accounts for a client.
  • Canopy is way to cache the upper N levels of a SPL ConcurrentMerkleTree.
  • Anchor events are used to emit information necessary to index changes made to a SPL ConcurrentMerkleTree
  • An Anchor generated module containing the program’s set of instructions, where each method handler in the #[program] mod is associated with a struct defining the input arguments to the method. These should be used directly, when one wants to serialize Anchor instruction data, for example, when speciying instructions on a client.
  • Module representing the program.
  • State needed to manipulate SPL ConcurrentMerkleTrees
  • Implements ZeroCopy over ConcurrrentMerkleTree generics


  • This applies a given function on a ConcurrentMerkleTree by allowing the compiler to infer the size of the tree based upon the header information stored on-chain
  • This macro applies functions on a ConcurrentMerkleT:ee and emits leaf information needed to sync the merkle tree state with off-chain indexers.
  • This applies a given function on a read-only ConcurrentMerkleTree
  • This applies a given function on a mutable ConcurrentMerkleTree




  • The static program ID


  • Confirms that a given pubkey is equivalent to the program ID
  • The Anchor codegen exposes a programming model where a user defines a set of methods inside of a #[program] module in a way similar to writing RPC request handlers. The macro then generates a bunch of code wrapping these user defined methods into something that can be executed on Solana.
  • Safety
  • Returns the program ID
  • Wraps a custom event in the most recent version of application event data

Type Aliases

  • Exported for Anchor / Solita Abstract type for 32 byte leaf data