BUMP: Understanding the BSV Unified Merkle Path Format

In a Nutshell

BUMP (BSV Unified Merkle Path) is a standard format for representing Merkle paths in the BSV ecosystem. Its goal is to use a single data structure to support both individual proofs and multiple related proofs while minimizing unnecessary data. Simply put, if a Merkle proof is the concept of "providing the path from a transaction to the Merkle root," then BUMP is the format for "how this path is standardized, encoded, and exchanged."

Why BUMP Is Needed

In earlier systems, Merkle proofs could be expressed in different formats, leading to several typical problems:

• Inconsistent formats for single-transaction proofs versus multi-transaction proofs
• Duplicate sibling hashes when proving multiple transactions from the same block
• Parsers needing conversion logic for different formats
• Proof size containing redundant data

The design motivation behind BRC-74 is to integrate these improvements into a new specification. This spec states that BUMP supports expressing multiple paths with the same data model and optimizes verification and data size through height, offset, and flag fields. In short, BUMP makes Merkle proofs more standardized, efficient, and suitable for transmission between applications in the BSV ecosystem.

What BUMP Contains

The top-level encoding of BUMP includes these key fields:

• block height: The block height, helping verifiers quickly locate the corresponding block header
• tree height: The overall height of the Merkle tree
• levels: Proof data for each level starting from level 0 (the leaf level) upwards
• leaves: The nodes that need to be provided at each level; a leaf can contain an offset, hash, txid flag, or duplicate flag

Compared to "just providing a list of sibling hashes," BUMP delivers more structured information, enabling the verification process to be performed precisely and automatically.

The Importance of Level 0

Level 0 of the Merkle tree is the transaction ID layer (leaf layer). In BUMP, level 0 can contain both the target txid that the client cares about and the sibling txids needed to compute the Merkle root. This design allows BUMP to express proofs for multiple transactions — for example, if two transactions in the same block share part of a path, BUMP can reuse some nodes instead of encoding two complete, duplicate proofs. This is one of BUMP's core advantages over simple single-path proofs.

Key Fields: offset, hash, txid, duplicate

In BUMP's JSON representation, a leaf typically involves these concepts:

• offset: The index of the node from the left in the current level; without it, a verifier cannot determine the hash's position in the tree
• hash: The hash value at that position
• txid: A boolean flag indicating whether this hash is a transaction ID that the recipient cares about, as opposed to a sibling hash used only for computing the root
• duplicate: Indicates that no extra hash is provided; instead, the working hash is duplicated according to Merkle tree rules. This handles cases of missing right-side nodes or odd-numbered nodes, reducing encoded data

Together, these fields enable a verifier to precisely reconstruct the computation of the Merkle root from BUMP.

How BUMP Computes the Merkle Root

The conceptual verification flow is:

1. Find the offset of the target txid at level 0
2. Combine with adjacent nodes to compute the hash for the level above
3. Repeat the process level by level
4. Arrive at the Merkle root
5. Use block height to locate the corresponding block header
6. Compare the computed root with the Merkle root in the block header

In the BSV TypeScript SDK, the MerklePath class can parse BUMP from hex or binary and compute the root. Example code:

verify() not only computes the root but also checks, via a chain tracking service, that the root corresponds to a valid block header.

Relationship Between BUMP and Ordinary Merkle Paths

An ordinary Merkle path is conceptual:

• Target txid + sibling hashes + left/right positions → Merkle root

BUMP is a standardized data format:

• block height + tree height + levels + leaves + flags

Therefore, BUMP is not a new hash algorithm, nor a replacement for the Merkle tree. It expresses the Merkle path using a data structure better suited for the BSV ecosystem.

Why BUMP Fits BSV

BSV's scaling approach means blocks can contain many transactions. Applications and wallets should not have to transmit redundant proofs for every transaction. BUMP addresses this through the following features:

• Supports merging multiple paths, reducing duplication among proofs from the same block
• Carries block height for quick block header lookup
• Unifies single and composite proofs into one format, lowering conversion costs between disparate systems

This is critical for proof exchange among SPV wallets, overlay services, transaction processors, and application backends.

What BUMP Cannot Solve

BUMP expresses only a Merkle path. It does not provide the following guarantees:

• It cannot, by itself, prove that a transaction script is valid
• It cannot prove that a transaction has not been double-spent
• It cannot prove that business data is genuine
• It cannot replace block header chain verification

The value of BUMP lies in standardizing inclusion proofs, not in replacing all verification logic.

BUMP's Position in the BSV Tech Stack

Within the BSV technology stack, BUMP can be positioned as follows:

• Transactions: Provide txid and transaction content
• BUMP: Provide the path from a txid to the Merkle root
• Block Headers Service: Verify that the Merkle root is in a valid block header
• BEEF: Package and transmit transactions together with proof materials like BUMP
• SPV Wallet / Application: Store and verify relevant data

BUMP is one of the foundational formats for SPV data exchange. Understanding BUMP makes it easier to understand BEEF.

Common Beginner Misconceptions

• BUMP is not a block header; it is only Merkle path data
• BUMP typically does not contain complete transactions; transactions must be provided separately or carried within BEEF
• BUMP is not a new consensus rule; it is a proof data format
• BUMP can merge multiple paths, but you must confirm that the block height and root match before merging
• Having a BUMP does not mean a transaction is trustworthy; you still need to verify the transaction, signatures, scripts, protocols, and the block header chain

References

• BRC-74 BSV Unified Merkle Path Format
• SPV and Merkle Proof Verification
• Merkle Proofs
• SPV Wallet docs