Metaplex Metaplex Bubblegum sets tree capacity, upfront rent, and proof size before the first compressed NFT mint
Metaplex Bubblegum requires a Bubblegum V2 tree before anyone can mint the first compressed NFT. That tree combines a Merkle Tree account with a derived TreeConfigV2 account. Max depth fixes lifetime capacity, max buffer size supports concurrent changes, and canopy depth shortens later proofs by caching upper nodes on-chain. Together, those immutable settings determine the account space and rent-exempt SOL balance required at creation. Start by bounding lifetime mints, expected write bursts, and the largest transaction your integration must compose. Then create the tree, fetch both accounts, and confirm their stored settings while the mint count remains zero.
The first use starts with two linked accounts
The Merkle Tree account and its derived TreeConfigV2 account must both exist before minting begins. One stores the concurrent Merkle tree, while the other records the Bubblegum-specific configuration and authorities.
The Merkle Tree account holds the changing root
The MPL Account Compression program owns the Merkle Tree account. Its header records max depth, max buffer size, tree authority, and creation slot. The account also contains recent change logs, the current tree state, and any configured canopy. Every mint appends a hashed leaf and changes the root, while later transfers, updates, delegates, and burns replace existing leaves.
TreeConfigV2 connects that structure to cNFT rules
Bubblegum derives TreeConfigV2 from the Merkle Tree address. It records the tree creator, tree delegate, total capacity, number minted, public flag, and leaf-schema version. The mint counter also supplies a tree-scoped nonce, so it does not move backward when an asset leaves circulation. Fetching this account after creation confirms that Bubblegum recognizes the new tree and that no first mint has occurred.
Capacity starts with max depth
Max depth controls how many leaves the tree can ever append. A tree with max depth d holds at most 2 d leaves. Depth 14 therefore provides 16,384 positions, depth 16 provides 65,536, and depth 18 provides 262,144. The SDK accepts predefined combinations of max depth and max buffer size, so two individually valid numbers do not necessarily form a supported pair.
Choose capacity from the expected lifetime mint count, not the number of assets expected to remain active at once. Count only successful mints, including replacement campaigns or later phases when they belong to the actual plan. Extra capacity raises the initial account requirement, while an undersized tree eventually forces new mints into another tree. Creation permanently records the selected depth.
How does canopy depth change proof size?
A canopy stores upper Merkle tree nodes inside the tree account. For a tree of depth d and canopy depth n, a truncated proof carries d - n sibling hashes. Each proof node occupies 32 bytes. A depth-20 tree with canopy depth 14 therefore needs six proof nodes, or 192 bytes, before the instruction adds its other data and accounts.
More canopy levels reduce the transaction space consumed by later leaf mutations. They also enlarge the on-chain account, and canopy storage grows rapidly as each added level contains more nodes. A shallow canopy lowers upfront rent but leaves less room for composing a Bubblegum operation with other instructions. The intended transaction shape, rather than capacity alone, should set this value.
The concurrency buffer absorbs recent tree changes
Max buffer size controls the change-log history available for concurrent writes. When another transaction updates the tree after an application fetched a proof, the compression program can use recent change logs to fast-forward that proof. If concurrent changes exceed the stored history, affected transactions can fail and require fresh proofs. Workloads with sharp bursts therefore need a different buffer judgment from occasional sequential minting.
A larger buffer consumes more account space and increases rent. It does not create more leaves or shorten a Merkle proof. Select an allowed depth-buffer pair that matches realistic write concurrency, then treat the canopy as a separate transaction-size decision.
Upfront SOL follows the exact account layout
Tree creation funds rent-exempt balances for the allocated on-chain accounts. Depth, buffer size, and canopy depth determine the serialized Merkle Tree account length, while TreeConfigV2 adds its own smaller allocation. Calculate the required account sizes with the current library, then ask the target Solana cluster for the minimum rent-exempt balance. That calculation is more dependable than carrying an old SOL estimate into deployment.
Reference configurations still show the scale of the choice. A depth-16 tree with buffer 64 and canopy 10 has been estimated near 0.7069 SOL, while depth 18 with buffer 64 and canopy 12 has been estimated near 2.1042 SOL. Recalculate before signing because cluster parameters, SDK behavior, and instruction fees can affect the final debit. The wallet also pays transaction charges and any active protocol fee.
Unused account space still increases the rent-exempt balance.
A hypothetical 50,003-mint sizing pass
The planned mint count, both candidate choices, and expected integration behavior are hypothetical. The capacity and proof calculations use the same dimensions for each choice: lifetime leaves, buffer size, truncated proof nodes, and reference tree rent.
Action one selects depth 16, buffer 64, and canopy 10. Capacity reaches 65,536 leaves, leaving 15,533 positions above the hypothetical requirement. The truncated proof contains six nodes, or 192 bytes. The reference tree-cost estimate is 0.7069 SOL, subject to a fresh rent calculation on the intended cluster.
Action two selects depth 18, buffer 64, and canopy 12. Capacity rises to 262,144 leaves, leaving 212,141 positions above the same requirement. This configuration also produces a six-node, 192-byte truncated proof, but its reference estimate rises to 2.1042 SOL. It buys capacity rather than smaller proofs.
The first choice fits the bounded mint count with the same proof length and less upfront rent. It remains suitable only if the intended application supports Bubblegum V2 and its planned transactions fit with that proof. Growth beyond 65,536 lifetime mints invalidates the capacity decision, even if earlier assets have been burned.
After creation, fetch the Merkle Tree header and TreeConfigV2. Their stored values, a zero mint count, and a confirmed creation transaction provide the completion evidence. If those values or the integration check fail, stop before minting. An authorized empty-tree closure can reclaim V2 tree and config rent while the tree still qualifies as empty.
What proves the tree is ready for its first mint?
A tree is ready when the creation transaction has confirmed and both resulting accounts report the intended immutable settings. A signature alone does not expose every configuration mistake.
Confirmation proves the creation instruction executed
Wait for the commitment level required by the application and retain the tree address from the confirmed transaction. A failed or expired transaction leaves no usable setup. A successful response identifies the account to fetch, but it does not replace inspection of the stored header and TreeConfigV2 fields.
Fetched state proves the configuration
Read max depth, max buffer size, canopy data, creator, delegate, capacity, public status, schema version, and number minted. Match them against the signed deployment record. The number minted should remain zero at this checkpoint. Any mismatch calls for investigation before the first leaf consumes capacity and removes the empty-tree exit.
The data path proves operational compatibility
The application also needs access to a Digital Asset Standard (DAS) API endpoint that returns indexed cNFT data and proofs after assets exist. Confirm Bubblegum V2 support across the intended read, display, transfer, and update paths. V1 support does not establish V2 compatibility, because the leaf schemas and trees are not interchangeable.
Keep the first mint unsigned until execution, stored state, and the planned data path agree. That pause preserves a clear boundary between tree setup and asset creation.
Access policy sits beside the sizing decision
The public flag changes who may mint, not the capacity or proof formula. A private tree limits minting to the tree creator or an approved tree delegate, while a public tree permits any account to mint. Record the intended authority and inspect the stored flag after creation. An accidental public setting expands mint access even when depth, buffer, and canopy are otherwise correct.
Failure boundaries belong in the sizing decision
A technically accepted configuration can still fail the application that must use it. Three boundaries deserve attention before the first irreversible leaf append.
A supported pair can still be operationally wrong
The program restricts max depth and max buffer size to supported combinations, but acceptance only proves structural validity. It does not prove enough lifetime capacity, suitable concurrency, or affordable rent. Model those requirements separately. If no supported pair matches them closely, several purpose-specific trees may be cleaner than one oversized account.
V1 and V2 cannot share one tree
Bubblegum V2 uses LeafSchemaV2 and requires a V2 tree created for that schema. A V1 tree cannot receive V2 leaves, and V2 instructions do not turn a legacy tree into a V2 tree. Collection compatibility also belongs in this check: a V2 cNFT associated with an MPL Core collection requires that collection’s BubblegumV2 plugin.
Proofs can consume the remaining transaction room
A proof competes with signatures, account keys, instruction data, and any companion program calls inside Solana’s transaction limit. Canopy truncation removes nodes already cached on-chain. Versioned transactions and Address Lookup Tables can reduce account-key pressure, but they do not repair a wrong tree configuration. Test the intended instruction composition with the selected proof length before funding a large tree.
Mint one asset before expanding the workload
Once the readiness checks pass, the next decision is whether the first cNFT belongs in this tree under its stored access policy and capacity budget. Preserve the tree address, configuration snapshot, authority record, and live rent calculation with the deployment record. Then mint one asset and confirm its returned leaf identity before expanding the workload.
Details worth knowing about Metaplex Bubblegum
Who supplies the SOL for a Bubblegum tree’s rent-exempt balance?
The transaction payer supplies the SOL that funds the Merkle Tree and TreeConfigV2 account allocations. In a Umi setup, the payer commonly comes from the active context, while the tree creator controls Bubblegum authority. Budget against the configured payer rather than assuming both roles use one wallet. The payer also needs enough SOL for transaction charges and any fee active for the invoked instruction.
Does burning a compressed NFT restore its tree capacity?
No, burning does not make that position available for a new mint. The burn replaces the asset’s leaf, while the tree’s mint counter and tree-scoped nonce do not move backward. Size the tree for the total number of successful mints over its lifetime, not the maximum number of assets expected to remain active. A campaign that repeatedly burns assets can still exhaust its original capacity.
Does a larger canopy make the first compressed NFT mint cheaper?
No, a larger canopy primarily reduces proof data for later operations that replace existing leaves. Bubblegum can append a new leaf using the rightmost proof maintained on-chain, so the first mint does not gain the same proof reduction. A deeper canopy increases the tree account allocation and upfront rent. Choose it for transaction composition and later asset operations, not as a promise of cheaper mint execution.
May one Bubblegum V2 collection span more than one tree?
Yes, tree capacity applies to each Merkle tree rather than to the collection as a whole. Assets in several V2 trees can reference the same compatible MPL Core collection when that collection has the BubblegumV2 plugin. Indexing and application logic must still preserve each asset’s actual tree address, leaf index, and proof. Splitting capacity therefore adds operational records even when the collection relationship stays consistent.
When should an application fetch a proof after minting begins?
Fetch the asset and its proof immediately before a transfer, update, delegate, freeze, verification, or burn instruction. Another tree modification can change the root after an earlier proof was retrieved. The change-log buffer may fast-forward some recent proofs, but it has a finite history. Long-lived proof caching creates avoidable stale-proof failures and should not replace a fresh Digital Asset Standard API request.
How much capacity headroom belongs above the planned mint count?
No protocol-wide percentage defines the correct headroom. Choose the smallest supported depth that exceeds the credible lifetime mint total, then compare its spare leaves and rent with the cost of adding another tree later. Include only growth paths that the project can reasonably identify. Burned assets still consume capacity, so the estimate should count completed mints rather than currently circulating cNFTs.