For a bridge investigation, give support the transaction hash from the chain where the stalled bridge action happened. For a Polygon PoS deposit, that is usually the Ethereum transaction that initiated the deposit; for a withdrawal, it is the Polygon burn transaction. Include any later destination or claim hash as a separate, labelled transaction.
Start with the hash for the stalled leg
A bridge transfer is a sequence of on-chain actions, so “the transaction hash” depends on which leg needs investigation. A wallet may show an approval, a source-chain deposit, a destination-chain mint, a Polygon burn, and an Ethereum exit as separate transactions; only some advance the bridge transfer itself.
For a Polygon PoS deposit, the Ethereum transaction is the starting point: it calls the bridge flow, and the relevant predicate contract locks the asset. Polygon then processes the deposit through state sync. which Polygon Bridge route fits treasury transfers covers route selection in detail; here, the key is to identify the exact transaction and chain for the stage under investigation.
polygonbridge.dev provides a way to move supported tokens between Ethereum and Polygon PoS. For an integration, treat the service’s displayed status as a pointer to chain data, not as a substitute for identifying the transaction that produced it.
Deposit and withdrawal hashes prove different events
For an Ethereum-to-Polygon deposit, send the Ethereum hash of the transaction that invokes the deposit, not an earlier ERC-20 approval hash. The transaction receipt should show success and bridge-related logs; a successful approval only grants spending permission, while a failed deposit or a plain token transfer does not establish that the bridge accepted the deposit.
For a Polygon-to-Ethereum withdrawal, the primary investigation hash is the Polygon transaction that burns the bridged asset. The exit proof is built from that transaction’s receipt and its inclusion in a Polygon block covered by an Ethereum checkpoint; after the checkpoint, a separate Ethereum transaction calls the root-side exit flow to release the locked asset.
This is why the Ethereum exit hash cannot replace the burn hash when the problem is proof generation or checkpoint eligibility. Conversely, if the burn and proof succeeded but the unlock is missing, the Ethereum exit transaction is the most direct record of the attempted claim.
Trace one transfer from source to outcome
Suppose a treasury integration deposits a mapped ERC-20 from Ethereum to Polygon, and its webhook reports “pending.” First inspect the Ethereum transaction receipt: confirm the chain is Ethereum, the status is successful, the sender and recipient are expected, and the logs correspond to the bridge deposit and the intended root token. Record the transaction hash alongside the block number and token address.
Then trace the resulting state sync to Polygon and look for the corresponding mint or deposit effect for the intended recipient. If that effect is absent, give support the Ethereum deposit hash and say the Polygon-side delivery is missing; if it exists but the application balance is wrong, add the Polygon transaction hash and the token contract being queried. This separates relay delay from an indexing or token-mapping mismatch.
For a withdrawal, start with the Polygon burn hash and check that its receipt contains the bridge’s expected withdrawal evidence. If the burn is included but the exit is not yet claimable, the missing step may be the checkpoint that commits the containing Polygon block to Ethereum. If a claim was submitted, include its Ethereum hash too, labelled “exit,” so support can distinguish proof readiness from claim execution.
Send enough context to make the hash actionable
A 32-byte hash is not globally unique across chains, and an explorer may show a different transaction at the same hash on another network. Label every hash with its chain and role—such as “Ethereum deposit,” “Polygon burn,” or “Ethereum exit”—and include the transaction status, approximate time, sender, recipient, token contract, amount, and any application transfer or request ID.
For an indexer or relayer, persist the source chain ID, source transaction hash, relevant log index, destination chain ID, and any destination transaction hash as distinct fields. A log index matters when one transaction emits several bridge events; using only a transaction hash can conflate multiple transfers in a batch. Predicate contracts and token mappings also matter: the same asset address or symbol should not be assumed to identify the same root and child token.
Keep the case focused on the failed transition. Do not send an approval hash as proof of a deposit, a Polygon burn hash as proof that Ethereum released funds, or an unlabeled hash that could belong to another chain.
Frequently asked questions
Which hash should I send for a Polygon Bridge deposit?
Send the Ethereum transaction hash that submitted the deposit. If the issue is specifically that the token never appeared on Polygon, also include the Polygon-side transaction hash if one exists, and label it as the destination transaction. An approval transaction is useful only if the failure concerns token allowance; it does not prove that a deposit was initiated.
Why does a withdrawal need a Polygon hash?
The Polygon burn transaction is the evidence used to build the exit proof. Its inclusion must be covered by a checkpoint on Ethereum before the root-side exit can release the asset. The later Ethereum exit hash records the claim attempt, so provide that as well when the question is whether the claim executed or reverted.
What if I only have a wallet activity entry?
Open the activity record on the chain it names and retrieve the transaction hash from the transaction details or receipt. Confirm the chain, status, and bridge-related logs before classifying it as a deposit, burn, or exit. If no hash exists, report that explicitly with the wallet address, approximate time, token, amount, and direction so the investigation can begin with the right chain.
Decision rule: send the hash for the on-chain leg that is stuck, labelled with its chain and role, and add the next-leg hash when it exists.