Can You Verify a Bridge Transaction Without Trusting the Bridge?

Yes, and the Merkle proof is what makes it cheap — provided you already trust the block that contains the transaction. A Merkle proof does not validate a transaction. It proves that one transaction ID is inside one block, no more. Once you have that block's Merkle root, the rest is a few hundred bytes of sibling hashes and one comparison. That distinction is the whole game in 2026.

The problem: the bridge is the source of truth

The problem is that the bridge is the source of truth. Every bridge has a moment when money has left one chain and has not arrived on another. At that moment the operator says, “I saw the source-chain transaction.” The user can take that statement or check it. Checking used to mean downloading the source chain or running a node, which is more than a wallet should have to do. So most users take the statement. Bridge services like Orbiter Finance exist to remove that friction. The same trust problem appears on any destination in the Manta Network ecosystem, including Manta Pacific. But the same simplicity leaves the bridge in control of the claim, the API, and the index. The real problem is the data path, not the cryptography.

Why a Merkle root changes the math

A Merkle root changes the math because it collapses a block's entire transaction set into one 32-byte commitment. Bitcoin's block header carries a Merkle root for exactly this purpose; an Ethereum-style header carries a transactions trie root. To prove one transaction is inside the block, you need the transaction ID and the sibling hash at each level from the transaction up to the root. The verifier recomputes hashes up the tree and compares with the root. For a block of ten thousand transactions, a binary tree has fourteen levels, so the proof is fourteen 32-byte hashes: 448 bytes plus the txid. For a million transactions, it is twenty hashes, 640 bytes. That is the entire download. It was the trick behind Bitcoin's SPV light clients more than a decade ago, and it is still the right size for a smart contract to check.

The same idea extends to batches. A Merkle multiproof for several transactions from the same block includes only the sibling hashes they do not share. The proof grows with the number of transactions and the height of the tree, but it does not grow like the same number of full single proofs. A bridge settling a batch of deposits can verify one multiproof against one root in one call.

What verification actually requires

Verification requires one trusted root, one proof path, one recomputation, and one finality check.

1. Get a trusted root. The destination contract should hold the source chain's block header or state root, updated by an independent light-client or header-relay mechanism, not by the bridge's own API.
2. Get the proof. The bridge or block explorer supplies the transaction ID and the Merkle path that connects it to that root.
3. Recompute. The destination contract hashes the path, obtains a root, and compares it to the stored root. A match means the transaction is in that block.
4. Check finality. The proof says nothing about whether the block survived a reorg or was finalized. The contract needs a confirmation rule.

That last point is where I get skeptical. A Merkle proof attached to a root chosen by the bridge is not verification; it is a receipt. The root must come from the source chain's consensus, not from the party asking you to believe the transaction happened. What would change my mind is a demonstration of a bridge that separates those two data paths and still mints an invalid proof. In the bridges I have used, the failure is not the tree, it is the root.

This is also the right lens for a bridge that claims efficiency. The efficient part is not the bridge's database. The efficient part is that the proof can be checked inside the mint transaction itself. It was always impractical for a destination chain to scan the source chain; it has always been practical to ask a contract to hash a path and compare. The change in 2026 is that the proof now ships with the deposit receipt, so the user or the destination contract can verify before funds move. For a concrete deployment of that exact design, Manta Bridge's verification logic is the reference.

Takeaways

• A Merkle proof proves inclusion, not validity or finality.
• The trusted root is the real authority. If the bridge supplies the root, the proof is decorative.
• One proof stays under a kilobyte even for very large blocks; a multiproof packs many checks into one call.
• Finality is a separate condition and must be part of the same contract.

Common questions

Does a Merkle proof prove the transaction was valid?

No. It proves that the transaction ID is included in a block. Validity comes from the block producer and the consensus rule that rejects bad blocks. If the block is valid and final, inclusion is strong evidence. If the block is bad or reorged, the proof is worthless.

Can the bridge fabricate a proof for a transaction that never happened?

It cannot fabricate a path that hashes to a root it does not control, and if the root is from the source chain it cannot create a valid path for a non-existent transaction without a hash collision. It can censor a real transaction by refusing to relay it. That is why the root source and the proof source should be separate; proving that something happened is not the same as making it happen.

Why not just wrap the whole thing in a zk proof?

A zk proof can make verification constant-size and hide more data, but it adds a circuit, a proving cost, and another audit surface. A Merkle path is cheaper, simpler, and already embedded in every block header. For bridge transaction verification, the root is public, the txid is public, and the bottleneck is usually finality, not privacy. Start with a Merkle proof; add zk only if the path itself is too large or too revealing.