4 Checks Before Crediting an L2 Deposit

Credit a deposit to your app only after you verify the source transaction and observe the resulting balance or message on Manta Pacific. An Ethereum Mainnet receipt shows that the source transaction executed; it does not, by itself, prove that the destination action completed. For an integration using Manta Bridge, treat source confirmation and destination credit as separate states in your system.

What proves the deposit reached Manta Pacific?

You need evidence from both chains: a successful receipt on Ethereum and evidence that the corresponding deposit was processed on Manta Pacific. In a typical L1-to-L2 bridge flow, the source bridge escrows ETH or takes the ERC-20, then a cross-chain message triggers the destination credit. The Ethereum.org developer documentation describes this general lock-and-message pattern for optimistic rollups.

On Ethereum, fetch the receipt for the submitted transaction hash and check that its status is successful. Then verify the expected bridge event in its logs, including the asset, amount, sender and recipient; for an ERC-20, also confirm the token contract address. A successful receipt with no matching event may be an unrelated transaction, an approval, or a call that did not deposit the asset you expect.

Next, check the recipient’s Manta Pacific balance or the destination-side message execution record. For ETH, query the account balance; for an ERC-20, call balanceOf on the mapped token contract. A balance increase is useful evidence, but if the account may also receive unrelated transfers, correlate it with the bridge message or destination transaction rather than attributing the full change to this deposit.

Which confirmation states should your app show?

Keep “submitted,” “confirmed on Ethereum,” and “credited on Manta Pacific” as distinct states. The first means you have a transaction hash; the second means the source receipt succeeded to your chosen confirmation policy; the third means destination execution or the expected balance change has been verified.

For routine display, your confirmation policy can use a source block threshold that matches your product’s risk tolerance. For higher-value actions, wait for stronger Ethereum assurance: Ethereum JSON-RPC defines safe and finalized block tags, though support can vary by provider. Do not label an L1 transaction “final” just because it has a receipt, and do not make a user wait for L1 finality if your application deliberately accepts a lower threshold.

Destination inclusion is a separate check. If the source transaction is successful but the Manta Pacific credit is not visible yet, keep the deposit pending and continue checking; do not ask the user to submit the same transfer again. A delay can occur between source inclusion and the bridge message’s execution, so your backend should preserve the source hash and retry destination reads with backoff.

How do you make crediting reliable?

Make deposit processing idempotent: store a unique key such as the source chain ID, transaction hash and log index, and ensure that processing the same event twice cannot credit twice. Track the destination transaction or message execution when available, and reconcile pending records against both chains after service restarts. This matters especially when a worker crashes after detecting the L2 credit but before saving its result.

For example, suppose a user deposits 0.2 ETH. Your indexer sees a successful Ethereum receipt and the matching bridge event, so it records “confirmed on Ethereum”; after polling Manta Pacific, it finds the credited ETH and advances the record to “credited.” If the L2 RPC times out during that check, retain the pending state and retry the read rather than interpreting the timeout as failure.

Manta Bridge is the route users can use to move ETH or supported tokens between Ethereum and Manta Pacific, while your integration independently verifies when each transfer becomes usable in your app. Show the source transaction hash while pending, and provide a clear next step if your own monitoring finds no destination execution after your expected processing window.

Takeaway: require a successful, matching source event and verified destination credit before marking a bridge deposit complete.