Skip to article Polygonfinance

Polygonfinance is a query about proofs for Polygon PoS bridge exits

Polygonfinance concerns Polygon PoS bridge exit proofs, which let Ethereum contracts verify a checkpointed burn before releasing tokens. A withdrawal begins with a burn on Polygon and finishes through an exit call on Ethereum. Before that exit, an Ethereum checkpoint must cover the Polygon block that contains the burn transaction. The proof-generation service assembles the exit payload from transaction data and checkpoint information. Fast confirmation on Polygon does not, by itself, complete that Ethereum withdrawal.

Key takeaway: A generated payload supports the Ethereum exit call; successful contract verification is the condition that permits the token release.

A burn starts a claim that Ethereum must verify

The native bridge withdrawal process burns the pegged tokens on Polygon, then uses an Ethereum exit to release the corresponding assets that the bridge holds there. Burning changes the Polygon side of the transfer. The Ethereum contract needs verifiable evidence of that change before releasing its assets. This explains why a successful burn transaction and an unfinished Ethereum withdrawal can coexist without contradicting each other. The separate MATIC-to-POL token migration concerns the network token, while this exit flow concerns a burn and its corresponding Ethereum asset release.

When can the service construct an exit proof?

The service can construct an exit proof once a valid Ethereum checkpoint covers the Polygon block containing the burn transaction. Polygon's own finality and Ethereum checkpoint inclusion answer different questions. Milestones finalize Polygon blocks locally, while checkpoints anchor block data on Ethereum. Only the latter supplies the checkpoint information that this exit proof requires. Waiting for a checkpoint therefore reflects a protocol dependency, even when the burn already appears finalized on Polygon.

Checkpoint submission follows a governance-controlled interval. The relevant readiness condition is inclusion of the burn's block, so a local confirmation time does not establish an Ethereum exit deadline.

The proof connects a receipt to an Ethereum checkpoint

An Ethereum exit through RootChainManager requires proof that the burn transaction belongs to a checkpointed Polygon block. The checkpoint provides the Ethereum-side anchor for verification. The transaction receipt supplies the burn event, and the Merkle proof establishes its inclusion in the Polygon block.

A burn hash identifies a transaction, but the exit contract also needs the encoded proof that establishes its inclusion.

Server-side generation keeps proof assembly out of the client

The proof-generation service assembles the exit payload on the server, fetching transaction data and constructing the proof before returning encoded bytes to the client. Its work includes retrieving the receipt, building a Merkle proof, finding the appropriate checkpoint header, and encoding the payload for the contract. These operations require sequential RPC calls and computation. Moving that assembly into a backend service lets a client request the completed payload without reproducing every data-fetching step inside a browser or mobile application.

The service primarily supports the Matic SDK.

What does the checkpoint inclusion response establish?

A successful block-included response identifies the Ethereum checkpoint that covers the requested Polygon block. Its fields include the block number, checkpoint range, root, and checkpoint header identifier. The range connects the requested block to a particular checkpoint. The response establishes the prerequisite for generating an exit payload, while the later Ethereum contract call performs the withdrawal.

A missing checkpoint changes the next proof request

Consider a burn whose block-included request returns HTTP 404. The API defines this status as no result found, which can mean that the block has not reached a checkpoint. The expected next state is a successful response identifying a checkpoint that covers the same burn block. A missing result alone does not establish the cause, so the block and network need to match the intended withdrawal.

Reading checkpoint status checks whether the prerequisite exists. Requesting exit-payload asks the service to construct evidence using that prerequisite. The status query leaves the withdrawal state unchanged, so it can guide another request before an Ethereum exit submission.

View full-size image

• Confirm that the requested block belongs to the intended burn transaction on the selected network.
• Use block-included to distinguish a covering checkpoint from a missing result.
• If the block has no valid checkpoint, continue checking inclusion before requesting another exit payload.
• After inclusion, request the payload with the same burn transaction hash and the relevant event signature.
• After an Ethereum exit submission, check its transaction outcome for the token release.

Request parameters identify the withdrawal evidence

The exit payload request combines a burn transaction hash with an event signature, and it can also include a token index.

The burn transaction hash

The required burnTxHash identifies the Polygon transaction that contains the burn. It is distinct from the hash of a later Ethereum exit transaction. Proof construction starts from the burn receipt.

The event and token selection

The event signature

The required eventSignature contains the keccak256 hash of the Transfer event signature. This parameter identifies the event type. The burn hash supplies the transaction context, so the event signature alone does not identify a particular withdrawal.

The token index

The optional tokenIndex selects a token's position in the burn transaction's token list.

View full-size image

A multi-token burn can yield several exit payloads

The all-exit-payloads method returns an array of payloads for all tokens in one burn transaction. It requires burnTxHash and eventSignature . This distinguishes a request for all token payloads from an exit-payload request with an optional tokenIndex . The choice concerns which proof material the service returns, rather than a different checkpoint rule for the same burn.

exit-payload returns a single encoded result, while all-exit-payloads returns an array. Its length does not establish the number of later Ethereum transactions or completed token releases.

RPC retries depend on matching network and provider pairs

The proof-generation service makes sequential RPC calls while assembling a payload, so an endpoint failure can interrupt the attempt and force proof construction to restart. Its configuration supports multiple endpoints to give a retry another provider.

Failover advances child-chain and parent-chain endpoint arrays together. At each index, MATIC_RPC pairs with ETHEREUM_RPC , while AMOY_RPC pairs with SEPOLIA_RPC . In this service configuration, paired endpoints must use the same provider, and the arrays in each pair must contain the same number of entries.

View full-size image

The mainnet configuration combines Polygon mainnet with Ethereum mainnet. Its testnet counterpart combines Polygon Amoy with Sepolia. Mixing those environments would change the chains from which the service requests its proof data.

For production deployments of this service, the configuration guidance calls for at least two RPC URLs per network. Additional endpoints provide alternative data access. They do not change whether Ethereum has received the checkpoint that the withdrawal requires.

Does a successful proof response complete the Ethereum withdrawal?

A successful proof response supplies an encoded payload; the withdrawal completes only when the Ethereum exit call verifies the burn and releases the tokens. The response's result field contains proof bytes. RootChainManager's exit() function consumes that material for verification. Generating those bytes and executing the contract call are separate operations with different results.

An application that displays a payload-generation success message has reported a service result. It still needs the Ethereum transaction outcome to describe the withdrawal as complete. A generated proof therefore cannot establish an asset arrival time by itself.

Exit proof rules follow the bridge mechanism

Polygon Portal's December 11, 2023 introduction included Socket and other third-party bridges, alongside swaps through third-party decentralized exchanges. A shared interface can therefore expose different mechanisms. The checkpointed-burn requirement described here belongs to the native Polygon PoS exit to Ethereum. A Portal label alone does not establish which bridge supplies a selected route.

A route that uses the native PoS burn-and-exit process carries its checkpoint prerequisite. If the selected route uses a different bridge, that bridge's own settlement and proof requirements determine completion.