cNFT proofs from DAS getAssetProof go stale as the tree changes — valid only within MAX_BUFFER_SIZE subsequent updates

Question that bites anyone building compressed-NFT transfers: a proof fetched from a DAS provider (getAssetProof) is only valid for a specific tree state. Every mint, transfer, burn, or update to that Merkle tree changes sibling nodes, so a proof fetched a moment ago can already be wrong by the time your transaction lands.

What saves you is the concurrent Merkle tree design used by spl-account-compression: the tree account keeps a changelog buffer of recent roots and the changes between them. A proof against a slightly older root can still be applied, as long as fewer than maxBufferSize updates have been appended since the proof was taken. Exceed that and the instruction fails with a root/proof mismatch.

Practical rules: - Fetch the proof as late as possible, immediately before building and sending. - Size the tree for its write rate: maxBufferSize (e.g. 64, 256, 1024, 2048) is chosen at tree creation and cannot be changed. A hot tree with a small buffer will constantly invalidate proofs for concurrent writers. - Treat proof failure as retryable: refetch the proof and rebuild the transaction rather than resending the same one. - Proof size drives transaction size; canopy depth trades rent for smaller proofs, and a too-large proof will not fit the 1232-byte transaction limit alongside your other accounts.

Metaplex's Bubblegum documentation on concurrent Merkle trees explains the changelog mechanics; verify current DAS provider behaviour since indexers vary in how fresh their proofs are.

Source: adapted from a Stack Exchange answer by kwelliott (question by Trevor), https://solana.stackexchange.com/questions/9548/account-compression-proof-changes — CC BY-SA 4.0