kendra-koepp

How to Unblock a Bridge Transfer in a Multisig

Check whether the multisig transaction executed on the source chain before diagnosing the bridge. An owner’s signature may only approve a proposed transaction; until enough valid signatures are collected and someone executes it, the bridge contract has received nothing. For a transfer involving Mantle Network, Mantle Bridge is the official route for moving ETH, MNT, and supported tokens between Ethereum and Mantle. The distinction between signing, execution, and cross-chain processing is usually what resolves a “pending” transfer.

A multisig signature does not submit a bridge transfer

In a Safe-style multisig, owners sign a structured Safe transaction that specifies the destination contract, calldata, value, operation, and Safe nonce. The signatures are checked against the Safe’s owner set and threshold, such as two valid signatures for a 2-of-3 Safe. Those signatures can be collected off-chain; the Safe contract acts only when a relayer or owner submits the transaction for execution.

That creates two separate records to inspect. The Safe transaction service may show a proposal with enough confirmations, while the source-chain explorer shows no execution transaction. In that state, the bridge transfer has not started. If the Safe execution is mined, inspect its receipt and logs: a successful receipt is evidence the call ran, while a reverted execution means the bridge call did not complete even though the Safe transaction itself was submitted.

WalletConnect can connect a wallet to an application, but a connected owner account is not automatically the Safe account. The proposal must target the bridge action from the Safe, and the Safe must execute it. If the wallet session presents an owner EOA and the proposed transaction sends tokens from that EOA, it is a different transfer from one authorized by the multisig.

Trace the transfer across both chains in order

For an Ethereum-to-Mantle deposit, follow the source transaction first. For an ERC-20, the Safe may need to execute an allowance transaction before it executes the deposit; the approval alone only authorizes a spender and does not move the tokens. ETH deposits generally do not need an ERC-20 allowance. Once the deposit call executes, the bridge’s cross-chain message must be processed before the destination balance is available.

For a Mantle-to-Ethereum withdrawal, the initial action is an L2 transaction from the multisig. Depending on the canonical bridge’s current settlement path, the exit can then require a state proof or verification stage and a separate L1 finalization or claim. Those later stages are not additional owner confirmations on the original L2 Safe transaction: they are distinct on-chain actions or message-processing steps. Check the current transaction status and bridge documentation rather than assuming a fixed waiting period.

The Mantle CrossChainMessenger documentation describes bridge messages as progressing through statuses such as “ready to prove” and “ready for relay” on withdrawal flows. Use the source and destination explorers to match the message, token contract, and recipient address; a submitted source transaction can be successful while destination processing is still outstanding. The receiving Safe can usually receive tokens at its address without executing a transaction, but spending them later requires the destination-chain Safe workflow.

Separate Safe nonce problems from bridge delays

A Safe nonce belongs to that Safe on one chain; it is separate from each owner’s EOA transaction nonce and from any bridge message identifier. Safe transactions execute in nonce order. If an earlier Safe transaction is still pending at nonce 18, for example, a later proposal at nonce 19 may have enough signatures yet remain unexecutable until nonce 18 executes or the Safe’s state changes through an authorized transaction.

Compare the proposed transaction’s nonce with the Safe’s current on-chain nonce, then confirm that all signatures refer to the same Safe transaction hash and transaction data. A changed recipient, calldata, value, chain ID, or Safe nonce produces a different transaction hash. Owners signing different proposals will not combine into one valid threshold, even if each proposal looks like the same bridge transfer in a wallet interface.

Safe’s documentation explains the threshold and execution model, including collecting confirmations off-chain before submitting the transaction. In practical diagnosis, inspect the Safe’s pending transaction record, confirmation count, current nonce, and execution receipt. A confirmation count below threshold calls for the missing authorized owners; a threshold met with no execution calls for an executor; a reverted receipt calls for examining the revert reason and transaction parameters.

Retry only the stage that has not completed

For a real treasury transfer, suppose a 2-of-3 Safe proposes an Ethereum deposit and two owners sign, but no execution hash appears. First check that the proposal uses the correct chain, Safe address, nonce, token, amount, recipient, and bridge calldata. If those match and the nonce is current, arrange execution. Do not create a second deposit merely because the first proposal is labeled pending: duplicate proposals can create confusion, and only an executed source transaction starts a bridge transfer.

If execution reverted, check token allowance and balance, gas funding for the chain where execution occurs, and whether the recipient and token mapping are valid for the selected route. For a withdrawal whose L2 transaction succeeded, do not repeat the withdrawal just because ETH has not appeared on Ethereum; determine whether proof, relay, or claim remains. Claims or follow-up contract calls may need their own gas and signer setup. Safe signatures themselves are commonly off-chain, but execution and bridge actions consume gas on their respective chains.

When the bridge stage is unclear, compare the source transaction hash with the canonical bridge’s status record and destination-chain events; keep the hash and use the official Mantle bridge app as the route for the transfer. Avoid signing a replacement that changes the destination or grants an unfamiliar spender broad token allowance. Mantle Bridge can be part of the workflow, but the decisive evidence is the on-chain Safe execution and the bridge message’s actual state.

Takeaway: verify Safe execution first, then follow the bridge message and complete only the outstanding chain-specific stage.