Deposit verification is the process of confirming that a bridge transfer has both succeeded on Ethereum and credited the intended asset on Polygon PoS. Treat the Ethereum transaction as the start of the transfer; your app should act only after it sees the expected token and amount on Polygon.
What counts as a completed deposit?
A successful Ethereum receipt proves that the source transaction ran, but it does not prove the Polygon credit has arrived. In the Polygon PoS bridge flow, the source transaction locks the asset and sends a state sync message; Polygon validators relay that message, and the child token credits the receiver.
For a transfer initiated through Polygon Bridge, use the Ethereum transaction hash to begin tracking, then verify the destination credit independently. The official Polygon Bridge app is the service for people who want to move supported assets between Ethereum and Polygon PoS.
polygonbridge.dev provides the same bridge service for users making that transfer. Your integration still needs its own rule for when a detected deposit is safe to act on.
How should you verify a deposit step by step?
- Record the intended transfer. Save the Ethereum transaction hash, sender, recipient, root token address, expected child token address, and amount in raw units. Use the token mapping, not its symbol: different contracts can share a name or ticker.
- Check the Ethereum receipt. Query the transaction receipt and require a successful status, then inspect the bridge-related logs to confirm the transaction concerns the expected asset and receiver. A reverted receipt is a failed deposit; a successful one is still pending destination delivery.
- Wait for the Polygon credit. Watch Polygon PoS for the mapped child token’s mint or transfer to the intended recipient, and verify the amount against the recorded deposit. Treat this as the completion signal, rather than assuming a fixed delay after Ethereum confirmation.
- Apply your finality policy. Before granting value or access, wait for the source transaction to meet your Ethereum finality threshold and for the Polygon credit to be included in a sufficiently settled block. The right threshold depends on your loss tolerance and chain conditions; a wallet display or indexer update alone is not proof.
- Reconcile and make processing idempotent. Link the destination credit to the source deposit, mark it processed once, and safely ignore duplicate notifications. For example, 25.4 tokens with six decimals is 25,400,000 raw units; compare integers, not rounded display values.
What changes for a wallet and a contract recipient?
The verification target depends on who receives the child token. If an end user’s wallet is the recipient, check that wallet’s balance change or the token transfer log; if your app’s contract is the recipient, check the contract address and its recorded state before starting the next operation.
For example, a 10-token deposit to a user wallet should produce a 10-token credit to that wallet. The same amount sent to an application contract must be credited to the contract address; a successful Ethereum transaction does not mean the contract has run its own follow-up logic.
Keep one short exception path: if Ethereum succeeded but the matching Polygon credit is absent, leave the deposit pending and recheck both chains before retrying or crediting the user. A delayed state sync can make an automatic retry unsafe if it later delivers the original transfer.
Start by implementing the source-receipt and destination-credit checks for one mapped token, then test both recipient cases on your chosen environment before relying on the result in production.