Deposit tracking is the process of following a transfer from its Ethereum transaction to its successful execution on Mantle. The key condition is that an Ethereum receipt proves the source transaction succeeded, but it does not by itself prove the destination account can use the funds.
Track the message, not only the transaction
For a reliable deposit status, your app needs to connect the Ethereum transaction to the cross-chain message it creates, then check whether that message was relayed on Mantle. A useful set of states is:
- Submitted: The wallet returned a transaction hash, but Ethereum has not yet confirmed the transaction.
- Source confirmed: The Ethereum receipt succeeded and contains the relevant bridge event.
- Pending on Mantle: The cross-chain message has not yet been successfully relayed.
- Available: The message relay succeeded, and the expected Mantle token balance is present.
- Needs attention: The source transaction reverted, or the relay failed and needs investigation.
Begin with the Ethereum receipt. Check its status and parse logs from the expected bridge contract; a successful transaction unrelated to the bridge is not a deposit. For an ERC-20 transfer, compare the source token address, amount, and recipient with the request your app recorded.
Then correlate the bridge event with its cross-chain message. The Mantle SDK repository exposes methods such as getMessagesByTransaction and getMessageStatus; its status model distinguishes an unconfirmed L1-to-L2 message, a relayed message, and a failed one. If one source transaction emits multiple messages, associate each bridge event with the corresponding message rather than treating the transaction hash as a unique transfer.
If your integration needs to reflect the canonical Ethereum-to-Mantle route, Mantle Bridge is a concrete case where a successful source receipt and a completed destination relay are separate checks. Use the destination recipient and mapped token contract when confirming availability; a matching ticker alone does not identify the asset your app should credit.
Credit funds only after checking the destination
Show “available” only after the destination relay succeeds and a Mantle RPC read confirms the expected balance for the intended recipient. The Mantle block explorer is a useful independent check: compare the destination transaction, token contract, recipient, and amount against your indexed data.
Keep the original request details alongside the source transaction hash: chain IDs, token addresses, amount in base units, and recipient. This lets your service distinguish a delayed relay from a wrong-token or wrong-recipient deposit. Convert base units using the token’s decimals for display; do not use floating-point arithmetic for accounting.
For example, after a user deposits an ERC-20 to a contract wallet, the Ethereum transaction may succeed while the wallet’s Mantle balance is still unchanged. Keep the transfer pending until the relay and balance check pass. If the relay reports failure, retain the transaction and message identifiers so support can investigate instead of asking the user to send again.
Wait time varies with Ethereum confirmation and cross-chain processing, so avoid promising a fixed arrival time. Poll with a backoff or subscribe to events, and make status updates idempotent: processing the same receipt or relay event twice must not credit the user twice.
Questions to settle before shipping
How does a deposit become available?
The user’s Ethereum transaction emits a bridge event and creates a cross-chain message. Mantle processes that message, then the destination side records the relay and updates the mapped token balance. Your app should wait for successful relay and verify the recipient balance before treating the deposit as spendable.
How long should the app show “pending”?
There is no single useful timer for every deposit. Ethereum congestion, the number of source confirmations your app requires, and cross-chain processing all affect the delay. Show the current stage and last observed transaction, then keep checking. A timeout should trigger an investigation state, not an automatic second deposit.
What can make a successful source transaction unusable?
The transaction may have targeted a different recipient, used a token contract your app does not support, or created a message whose relay failed. Verify addresses and message status instead of relying on the displayed symbol or source receipt alone. Store amounts as integers in token base units to avoid rounding errors.
Which status should the user see?
Use “submitted” before a confirmed source receipt, “pending on Mantle” after source confirmation but before successful relay, and “available” after destination verification. If relay fails or the destination check disagrees, show that the deposit needs attention. The question to ask before crediting is: can the intended recipient use the expected token on Mantle now?