How to reconcile recurring Manta bridge transfers

For a treasury batch of 10 transfers, reconcile each movement as its own two-chain state transition, keyed to the source transaction and the destination receipt. A balance change alone cannot show which deposit arrived, which token representation was credited, or whether a withdrawal has completed. Keep one record per transfer and close it only against evidence from both chains.

Define the transfer record before sending

A useful record binds the business payment to its onchain movement: direction, source and destination chain IDs, asset, raw amount, sender, recipient, source transaction hash, and the transaction log index. The hash identifies a transaction; the log index distinguishes multiple bridge events emitted by that transaction. Store the decimal precision used to convert the raw integer into a displayed token amount.

For an Ethereum-to-Manta Pacific movement, record chain ID 1 as the source and 169 as the destination. For a return transfer, reverse them. The Manta bridge service is a way to execute the transfer between those networks; your treasury ledger should still identify the asset by its source token address and its corresponding destination representation, not by ticker alone.

That distinction matters for USDC and other ERC-20s: identical symbols do not prove identical contracts or redemption rights. Before a recurring run, verify the source contract and the canonical Manta Pacific token mapping against the network’s published token data. Record both addresses and decimals in the asset master, then compare the amount in integer base units to avoid rounding discrepancies.

Match the source event to the destination credit

A deposit is not a swap: the L1 bridge receives or escrows the source asset, then cross-domain messaging causes the mapped balance to be credited on Manta Pacific. Reconcile the bridge event and amount on Ethereum to the corresponding deposit or mint-side event and recipient balance change on Manta. The latter is the operational receipt; the source transaction being mined is not, by itself, proof that the destination account can spend the funds.

1. Create the payment instruction. Assign a treasury batch ID and capture the intended recipient, asset, and exact amount before anyone signs. This lets finance link the eventual bridge event to the business purpose without relying on a wallet’s current balance.
2. Record the source transaction. After submission, save its hash and inspect the successful receipt for the bridge event, token address, amount, and recipient. For an ERC-20 deposit, include the approval transaction in the audit trail if one was needed; an approval changes allowance, not token ownership.
3. Wait for destination evidence. Find the corresponding message execution or token credit on Manta Pacific and compare its recipient and raw amount with the instruction. Mark the transfer received only when that destination evidence exists and the account can use the funds.
4. Close the record and reconcile fees separately. Post the asset movement at the received quantity, and record Ethereum gas and any Manta gas as separate expenses in their native units. Do not net gas against the bridged principal unless your accounting policy explicitly requires that presentation.

Keep withdrawals open through finalization

A withdrawal has a different lifecycle from a deposit: initiating it on Manta Pacific records an exit, but Ethereum funds are released only after the withdrawal message becomes provable, is proven on L1, clears the applicable challenge period, and is finalized. Treat the initial L2 transaction as “initiated,” not “paid.” For a treasury forecast, reserve the amount as in transit until the L1 release is visible.

Store the L2 withdrawal transaction hash, the proof transaction hash, the challenge-period status, and the finalization transaction hash as separate milestones under one transfer record. The exact elapsed time depends on the rollup’s current proving and finalization process, so a fixed internal cutoff should trigger investigation rather than an assumption that the transfer failed. If a withdrawal remains pending, check which milestone is missing before retrying; a second withdrawal can create a duplicate obligation.

Resolve exceptions from events, not balance guesses

The most common reconciliation breaks are a wrong recipient, a mismatched token mapping, a source transaction that reverted, and a destination credit that has not yet executed. A treasury sweep can also obscure attribution: if several deposits land at one address, do not allocate a balance increase to a payment unless event-level amount and recipient data match. Keep a short exception status such as “source confirmed,” “message pending,” or “destination credited,” with the relevant hash attached.

Before releasing a batch, have a second operator compare chain IDs, recipient addresses, token contracts, and raw amounts against the approved instruction. Test the reconciliation with one small transfer when adding an asset or changing the contract mapping; this catches decimal and address-book errors before they multiply across payroll or supplier runs.

Would you still release this batch if every transfer had a matching source transaction but one had no confirmed destination credit?