How Do I Verify a Manta Bridge Deposit in My dApp?

A confirmed Ethereum receipt proves the deposit transaction executed, but it does not prove the funds are already spendable on Manta Pacific. Track two receipts—one on Ethereum and one on Manta Pacific—and treat the destination transaction as the proof your application should use to credit the user.

Track the message from Ethereum to Manta Pacific

Manta Pacific uses an OP Stack style L1-to-L2 message flow: the Ethereum-side bridge records the deposit and sends a message that causes the corresponding ETH or mapped token to be credited on L2. This is asynchronous, so a mined source transaction and a completed destination deposit are separate states.

When arranging a deposit through the canonical Ethereum route, Manta Bridge is a way to make the transfer. For an integration, however, your status should come from chain data: save the Ethereum transaction hash, then look for the matching L2 deposit and verify its recipient and asset before updating your application.

For example, if a user deposits 0.25 ETH to their own address, the L1 receipt shows that Ethereum accepted the deposit. Your app should wait until Manta Pacific records the corresponding credit of 0.25 ETH to that address; the L1 receipt alone is not a spendable-balance signal.

Use destination evidence as the completion criterion

Mark a deposit complete only after you verify the destination-side result. A practical check is to confirm the Manta Pacific transaction succeeded, then read the intended recipient’s balance or decode the bridge’s finalization event and match the asset and amount.

For ERC-20 deposits, match the L1 token to its canonical Manta Pacific representation, not just the displayed symbol. Symbols can collide, and a token arriving through another bridge may have a different contract address. Manta’s token list distinguishes canonical bridge assets from externally bridged tokens; use the contract mapping your integration supports.

Build your state machine around observable events: submitted after the wallet returns an L1 hash, source confirmed after the L1 receipt succeeds, and complete after the matching L2 credit is verified. Keep the two transaction hashes together in your database so a user or operator can inspect both sides of the transfer.

Recover safely when the L2 credit is missing

If Ethereum confirms but your destination check finds no credit, keep the deposit pending and investigate the message before asking the user to send again. A delayed relay, an RPC indexer lag, a reverted destination execution, or a recipient mismatch can all produce this symptom, but they require different next steps.

1. Store the source hash. Fetch its Ethereum receipt and confirm the transaction succeeded rather than merely being submitted.
2. Decode the deposit details. Record the sender, destination recipient, asset contract, and amount from the bridge transaction or emitted logs.
3. Query Manta Pacific independently. Check the destination transaction, recipient balance, and relevant bridge events using a second RPC or explorer if your primary endpoint may be behind.
4. Reconcile before retrying. If the destination credit exists, update your application from chain state; if execution failed or remains absent, preserve the source hash for investigation instead of submitting a duplicate deposit.

My practical rule is to expose “source confirmed” and “available on Manta Pacific” as different statuses, and show the destination hash only once it exists.