Every Polygon transaction goes through the same journey: it is created, signed, broadcast, held in a mempool, picked by a block producer, included in a block and finally made irreversible. Most of the time this takes seconds and nobody notices. When something goes wrong, such as a stuck transaction, a nonce gap or a sandwiched swap, understanding the lifecycle tells you why. This guide walks through each stage on Polygon PoS and explains where the mempool fits.
In short: a Polygon transaction is signed locally, sent to an RPC endpoint with eth_sendRawTransaction, held in node transaction pools (the mempool) while it waits, included in a block by a block producer, and finalized by validator milestones, typically within a few seconds. While it waits in the public mempool, it is visible to anyone watching.
Polygon PoS in one paragraph
Polygon PoS is an EVM-compatible network with two main layers. Bor is the execution and block production layer, based on Go Ethereum (geth); it runs the transaction pool and builds blocks. Heimdall is the validator layer that manages staking and the validator set, coordinates which validators produce blocks and handles finality. Since the Rio upgrade in October 2025, validators elect a small pool of block producers under Validator-Elected Block Producer (VEBloP), with one producer building blocks for a longer span and backups ready. Periodically, Heimdall checkpoints ranges of Polygon blocks to Ethereum. The network’s gas token is POL, and mainnet uses chain ID 137.
Stage 1: Creating the transaction
A transaction describes what you want to do. Its main fields are:
- to: the recipient address or contract.
- value: the amount of POL to send.
- data: encoded contract call data, empty for a plain transfer.
- nonce: the sender’s transaction counter. Each nonce can be used once, in order.
- gas limit: the maximum gas the transaction may use.
- maxFeePerGas and maxPriorityFeePerGas: the EIP-1559 fee fields. You pay the protocol base fee plus a priority fee, up to your maximum.
- chainId: 137 for Polygon PoS mainnet.
Wallets and libraries fill most of these in for you, using RPC calls such as eth_getTransactionCount, eth_estimateGas and eth_feeHistory.
Stage 2: Signing
The transaction is signed with the sender’s private key. Signing happens locally in the wallet or application; the key never needs to leave it. The signature proves who sent the transaction and covers the chain ID, which prevents replay on other networks. The result is a compact blob of signed bytes, and its Keccak-256 hash is the transaction hash you will see on Polygonscan.
Stage 3: Broadcasting
The signed transaction is submitted to an RPC endpoint with eth_sendRawTransaction. The node checks that the signature is valid, the nonce is not already used, the fees meet its minimum and the sender can afford the worst-case cost. If anything fails, you get an error immediately. If it passes, the node returns the transaction hash.
Stage 4: The mempool
Accepted transactions go into the node’s transaction pool. There is no single global mempool: each node keeps its own pool and shares transactions with its peers, so in practice a broadcast transaction spreads across the network within moments. Together, these pools are what people mean by the Polygon mempool.
Inside a pool, transactions fall into two groups:
- Pending (executable): the next nonce in line for the sender, ready to be included.
- Queued (not yet executable): waiting on an earlier nonce. If nonce 5 is missing, nonce 6 and above wait in the queue.
A few rules from geth’s transaction pool, which Bor builds on, matter in practice. Node operators can configure them, so treat these as typical behavior rather than fixed values:
- Replacement. Sending a new transaction with the same nonce and higher fees replaces the old one. Nodes require a minimum increase, 10% by default in geth.
- Minimum fees. Polygon nodes enforce a minimum priority fee. Transactions below it are rejected or never picked up.
- Limits and eviction. Pools have size limits. When they fill up, the lowest-paying transactions can be dropped, and transactions stuck in the queue can expire after a configured lifetime.
Who can see the mempool
Anyone running a node, or using a service that streams pending transactions, can see what is in the public mempool, including the decoded details of swaps and contract calls. That transparency is useful for wallets and explorers. It is also what frontrunning and sandwich bots rely on. We cover the consequences in MEV protection on Polygon.
Stage 5: Selection and inclusion
The active block producer selects transactions from its pool, orders them and builds a block. Fees influence selection: a higher priority fee generally makes a transaction more attractive to include early. Once the block is produced and propagated, the transaction has its first confirmation and a receipt is available from eth_getTransactionReceipt, with status 1 for success and 0 for a revert.
A reverted transaction is still included and still pays for the gas it used. It is a failure of the contract call, not of the network.
Stage 6: Finality
On Polygon PoS, finality comes from milestones. Validators agree on the latest blocks they have seen, and when at least two thirds of them back a sequence, it becomes final. According to the Polygon documentation, milestones typically finalize a transaction within 2 to 5 seconds, and finalized blocks are irreversible. You can check with eth_getBlockByNumber("finalized", false): if the finalized block number is at or above your transaction’s block, it is final.
Checkpoints are a separate mechanism: Heimdall periodically submits a commitment covering a range of Polygon blocks to Ethereum. They matter for withdrawals to Ethereum and anchor Polygon’s history there, but a transaction is final on Polygon well before the next checkpoint.
Where private submission fits
Private submission changes stage 3 and stage 4. Instead of sending the signed transaction to a public RPC that broadcasts it into the public mempool, you send it to a private RPC endpoint that routes it toward block production privately. Creation, signing, inclusion and finality are unchanged, and the transaction is public once included. See what private transactions on Polygon are and how to send them.
Common problems and what causes them
| Problem | Likely cause | Fix |
|---|---|---|
| Transaction stuck as pending | Fee too low for current conditions | Replace with the same nonce and higher fees |
| Later transactions not confirming | A missing or stuck earlier nonce | Fill or replace the missing nonce |
| Transaction disappeared | Dropped from pools (low fee, pool limits, expiry) | Check the nonce, then resend |
| Included but failed | Contract call reverted | Inspect the receipt and revert reason |
| Worse price than quoted | Market movement or MEV such as a sandwich | Tighten slippage and consider private submission |
Frequently asked questions
Is there one Polygon mempool?
No. Each node has its own transaction pool and shares transactions with peers. The combined set of pending transactions across public nodes is what people call the Polygon mempool.
How long does a Polygon transaction take to be final?
Inclusion usually takes seconds. According to the Polygon documentation, milestones typically finalize transactions within 2 to 5 seconds after that.
Can I cancel a Polygon transaction?
Only before it is included, by replacing it: send a new transaction with the same nonce and higher fees, often a zero-value transfer to yourself. Once included, it cannot be undone.
Why can bots see my transaction before it is confirmed?
Because transactions sent through public RPC endpoints are shared across node transaction pools while they wait. Private submission avoids that public stage.
Conclusion
The Polygon transaction lifecycle has six stages: creation, signing, broadcasting, the mempool, inclusion and finality. Most problems, from stuck transactions to sandwiched swaps, trace back to what happens in the mempool. Knowing how it works lets you set fees and nonces correctly, replace transactions when needed, and decide which transactions should skip the public mempool altogether.
Hyperstrate provides private transaction submission for Polygon. Explore Polygon private RPC infrastructure, read how a Polygon private RPC works, or contact us.
