How to audit Manta withdrawal release proofs

To audit a Manta Pacific withdrawal, match the L2 message to its output root, verify the inclusion proof on Ethereum and confirm the portal records the withdrawal as proven before it is finalized.

What does a withdrawal proof show?

The OP Stack withdrawal specification describes a proof that shows a withdrawal message was recorded in the L2-to-L1 message passer’s storage. The message contains the destination, value, sender and call data; its hash must match the leaf proven by the storage inclusion path.

Manta’s published OptimismPortal contract exposes a proof function that takes the withdrawal, an output index, output-root fields and a proof path. For background on how routes differ, see this guide to native and routed Manta bridge paths; the route determines which system’s proof and release rules apply.

Which fields should you check?

Start with the L2 transaction that initiated the withdrawal, then compare the proof data with the L1 portal record. The portal contract’s interface identifies the fields needed to check that relationship:

• Withdrawal: compare sender, recipient, value, gas limit and data with the L2 transaction.
• Output: confirm the output index and that the supplied state root, message-passer storage root and block hash reconstruct the referenced output root.
• Inclusion: check that the proof path places the withdrawal hash in the message-passer storage committed by that root.
• Portal status: look for a matching proven-withdrawal record and check its output reference and timestamp.

A successful wallet prompt or bridge-history label is not proof that these fields match. Verify the transaction hashes and contract events against the relevant chain records.

When is the withdrawal released?

Proof submission and release are separate steps: the portal first accepts a proof, then permits finalization once the applicable waiting or challenge condition is met. The OP Stack specification describes finalization through the portal after that period; Manta’s fast-finality design can affect withdrawal timing, so check the current portal and output status instead of assuming a fixed delay.

Before finalizing, confirm the same withdrawal remains proven, the output is eligible and the portal has not already marked it complete. The useful audit result is a matched L2 message, valid inclusion under its output root, and an L1 finalization record for that same withdrawal.