How Polygon PoS State Sync Delivers a Deposit

Polygon PoS state sync delivers a deposit by carrying a message from an Ethereum contract, through Heimdall, to a contract on Bor that mints the matching token. The Ethereum transaction locks the original asset first. Validators relay its event, and Bor executes the message on Polygon. The user gets a token they can use on Polygon; the original remains locked on Ethereum.

What happens when a user deposits through the Polygon PoS Bridge?

A deposit starts when the user calls the bridge’s Ethereum-side contract. The contract checks that the asset is supported and mapped to a Polygon token. For a token deposit, a predicate contract locks the asset; it does not send the Ethereum token across the network. The bridge then asks StateSender to publish a message containing the information needed on Polygon, such as the recipient and amount.

That event is the handoff point. State sync is the delivery path for the message, while the bridge contracts define what the message does. For a fuller walk-through of how Polygon’s bridge moves tokens between Ethereum and Polygon, see the companion guide. Here, the key point is that the event announces a deposit; it does not itself mint the Polygon token.

How do Heimdall and Bor carry out state sync?

Heimdall validators observe eligible events on Ethereum and record their message data as pending state syncs. Heimdall is the coordination layer. Bor is the execution layer that produces Polygon PoS blocks and runs the child-chain contracts. Bor requests pending messages from Heimdall and processes them in sequence as part of block execution.

Think of Heimdall as a dispatch desk passing an instruction to the workshop. The analogy stops there: the actual systems use validator consensus, event records, and deterministic contract calls. Each Bor node must process the same eligible messages in the same order, so they reach the same chain state.

• Ethereum bridge contract: locks the original asset and initiates the message.
• StateSender: emits the event that carries the deposit instruction.
• Heimdall: records eligible events for delivery to Bor.
• Bor and the child-chain manager: execute the instruction and mint the mapped token for the recipient.

The child-chain manager receives the message and calls the relevant token logic. That logic mints the matching Polygon representation to the recipient. The user can then transfer or use that token on Polygon. The bridge’s mapping connects the Ethereum asset to its Polygon counterpart; state sync transports the instruction, not the asset’s bytes or ownership record.

Why can a deposit take time to appear on Polygon?

A deposit appears after the Ethereum event has been observed, accepted for relay, and processed by Bor. These are separate steps, so an Ethereum transaction confirmation does not mean the Polygon token has already been minted. A queue or interruption in event processing can delay delivery even while Polygon blocks continue to be produced.

For a deposit in progress, check both sides of the route: first confirm the Ethereum transaction succeeded and locked the asset, then check whether the corresponding Polygon transaction or balance update has appeared. If the first step succeeded and the second has not, the state sync may still be pending. The lock-and-mint design keeps the original on Ethereum while the matching representation is used on Polygon; the relay is what connects those two contract actions.