Read the Ethereum Deposit Log Before You Switch Chains

Read the Ethereum transaction receipt and confirm the bridge’s deposit event before switching networks; a successful receipt alone does not prove that Polygon credited the destination account. For a Polygon PoS ERC-20 deposit, the root-chain flow calls RootChainManager.depositFor, which passes the token and deposit data to a token predicate. That predicate handles the token movement and emits a deposit event. The Polygon PoS process then sends deposit data through state sync for the child chain to process. The log is evidence about the Ethereum step, not a receipt for the later Polygon step.

Which log confirms an Ethereum bridge deposit?

For a Polygon PoS ERC-20 deposit, look for the relevant predicate’s LockedERC20 event in the Ethereum transaction receipt. A standard ERC-20 predicate can emit that event with the depositor, destination receiver, root token and amount. The exact event depends on the predicate and deployed contract, so identify the bridge path and check its ABI rather than assuming every token uses the same event.

Ethereum’s eth_getTransactionReceipt method returns the transaction’s execution status and its logs. Each log has an emitting contract address, topics and data. For a non-anonymous event, topic zero contains the event signature hash; indexed arguments appear in later topics, while non-indexed arguments are ABI-encoded in data. Decode those fields with the ABI for the emitting contract. A block explorer’s event display can help, but it is a decoded view of these receipt fields.

For wider context on what happens after the source transaction, this comparison of Polygon Bridge withdrawal paths covers the exit side of the flow. Deposit and withdrawal logs serve different steps: an Ethereum deposit event does not prove that a later Polygon withdrawal has completed.

How do you check the receipt before changing networks?

Check the receipt’s status, then match the log to the expected contract and transaction details. A receipt status of success means the EVM transaction completed without reverting. It does not establish that the intended bridge contract was called, that the expected asset was deposited, or that a destination-chain action has finished.

• Confirm the source transaction. Match the transaction hash and Ethereum network to the deposit you initiated. A pending transaction has no receipt yet.
• Check the receipt status. If execution failed, the receipt status is zero and the transaction’s state changes and logs are reverted. A successful status is necessary, but not sufficient.
• Identify the emitter. Verify the log address against the relevant deployed predicate or bridge contract for the route. A familiar event name from an unverified address is not evidence of a canonical deposit.
• Decode and compare. Check the event signature and the decoded depositor, receiver, root token and amount against the intended transfer. Compare token addresses, not just symbols.

Do not mistake an ERC-20 Approval or Transfer log for the bridge deposit event. An approval authorizes a spender to move tokens; it does not itself move them into the bridge. A token transfer can be one part of the deposit transaction, but the bridge-specific predicate event identifies the deposit call’s arguments. Some deposit routes or token types use different predicate logic, so an expected ERC-20 event may not apply.

Does a successful Ethereum log mean Polygon has credited the funds?

No. On the Polygon PoS ERC-20 path, the root-chain deposit flow calls RootChainManager.depositFor. The manager invokes the mapped predicate’s lockTokens function, then sends encoded deposit data through StateSender.syncState. On the child chain, ChildChainManager.onStateReceive handles the state-sync message and calls the mapped child token’s deposit function. These are distinct execution steps on different chains.

The Ethereum receipt can confirm the source-side event and its arguments. To verify the result, inspect Polygon for the corresponding destination-side processing and the balance of the event’s receiver. A delay between the source receipt and destination credit does not by itself mean the Ethereum transaction failed; the steps have separate execution and confirmation paths. If the destination account differs from the connected wallet, check the event’s receiver before deciding which address should show the balance.

Switching the wallet’s selected network changes which chain the interface queries and where new transactions would be sent. It does not move funds or complete bridge processing. Preserve the Ethereum transaction hash, verify the bridge log against the intended route, then check the receiver on Polygon. That sequence separates source execution from destination delivery, which is the distinction the receipt alone cannot make.