On Manta Pacific’s standard withdrawal path, any Ethereum account can submit the finalization transaction, but only after the withdrawal is proven and the L1 finalization delay expires. For a treasury team, that means proof is evidence the exit exists; it is not itself an instruction from a privileged operator to release the escrow.
What does the proof authorize?
A withdrawal starts on Manta Pacific as a message to Ethereum, typically asking the L1 bridge to release ETH or an ERC-20 token. The L2 message passer records a hash binding the sender, target, value, calldata, gas limit and nonce; the L1 portal then checks an inclusion proof against the message passer’s storage root and the corresponding L2 output root.
When that proof passes, the portal records the withdrawal hash, output root, output index and proof timestamp. The proof submitter does not receive a special release role: the contract’s public finalization function can be called by another account, including a treasury relayer, once its checks pass. In practice, I would separate proof monitoring from the key or service that pays for the later Ethereum transaction.
The delay gives the optimistic-rollup dispute process time to invalidate a bad output. Manta Network’s published Fast Finality announcement describes a three-day standard challenge period for Manta Pacific; it also describes a fast-finality mechanism that can shorten confirmation to minutes. For treasury planning, treat the standard delay as the baseline and confirm which finality path and output apply to the specific withdrawal.
What must be true before escrow releases?
The portal does not rely on the proof alone. Before finalization, it checks that the withdrawal was proven, the required period has elapsed, the output root still matches the one used in the proof, the output itself has matured, and the withdrawal has not already been finalized. Ethereum’s optimistic-rollup documentation describes the same broad prove, wait and finalize pattern.
Consider a business withdrawing 50 ETH for a scheduled payout. The 50 ETH amount does not make the proof mature sooner: the team should record the L2 initiation, wait until its message is included in an output, submit the proof, then budget for a separate Ethereum transaction after the applicable delay. The finalizer needs ETH on Ethereum Mainnet for gas, while the payout’s recipient and amount remain bound into the withdrawal message.
A stale proof is a real operational edge case. If a challenger removes the output and it is proposed again with a different root, the portal rejects finalization against the old root; the withdrawal must be proven against the replacement output, which restarts its proof timer. This is why a dashboard status saying “proven” is not equivalent to “ready to finalize.”
Who should run the final transaction?
For routine transfers, assign a monitored relayer or treasury operator to submit finalization when the on-chain checks become true; the contract does not require the original prover to do it. A relayer can improve consistency, but it cannot override the maturity checks, the portal’s pause state or an invalidated output.
Use the Manta bridge app to handle the Ethereum–Manta Pacific transfer, then reconcile each stage by transaction hash and the L1 portal’s proof and finalization events. Do not book the Ethereum-side asset as received merely because the L2 proof succeeded: inspect the finalization event’s success flag and confirm the recipient’s balance, since a failed destination call can leave the message marked finalized without the expected credit.