Checkpointing: the security model nobody explains
Polygon PoS is a sidechain with its own validator set, not a rollup. It produces blocks independently and periodically commits a checkpoint — a Merkle root of recent blocks — to a contract on Ethereum.
The distinction matters. A rollup posts its transaction data to Ethereum, so anyone can reconstruct and verify the chain from L1 alone. Polygon PoS posts a summary. Ethereum knows what Polygon claims happened; it cannot independently verify it. Security rests on Polygon's own validator set, with checkpoints providing a settlement anchor rather than a proof.
For everyday use this is irrelevant. For bridge withdrawals it is the entire timeline: a withdrawal cannot complete on Ethereum until the checkpoint covering it has been submitted, which is why withdrawals take far longer than the block time implies.
PolygonScan has the checkpoint data. It does not connect it to the withdrawal experience anywhere a confused user would find it, which is why this section exists.
MATIC, POL and the confusion that followed
Polygon's native token migrated from MATIC to POL in 2024. The token contract changed, the ticker changed, and a great deal of documentation, tooling and third-party content did not.
The practical consequences are ordinary but persistent. Older guides reference MATIC. Some interfaces still display the old symbol. And — the part that matters — a token named MATIC may now refer to the legacy contract, the new one, or something entirely unrelated that somebody deployed to exploit the confusion.
The rule that always applies: verify the contract address, never the displayed name. Token names and symbols are arbitrary strings chosen at deployment and are not unique. This is true on every EVM chain and it is the single most reliable defence against token impersonation.
It is worth applying the same scepticism to any figure quoted about Polygon supply or market data from before the migration. The numbers may be accurate and refer to a different token.
Reading an address with a hundred thousand transactions
Polygon fees are small fractions of a penny, which means applications transact freely in ways they never would on Ethereum. Gaming contracts, loyalty schemes and micro-payment systems generate address histories in the hundreds of thousands.
PolygonScan copes with this better than you might expect. The filters work, pagination holds, and CSV export exists — which for reconciliation or accounting is often the only practical route, since no amount of scrolling gets you through a year of activity.
Three things worth knowing when wading through one. Internal transactions are on their own tab and are where contract-to-contract value movement appears, so a main transaction list can look almost empty while significant value moved. Token transfers are likewise separate, because they are log events rather than transaction fields. And the date filter is the tool to reach for first — narrowing to a window before doing anything else turns an impossible page into a manageable one.
If you need heavy historical extraction rather than a lookup, an explorer API is the wrong tool entirely. Dune or a self-hosted Blockscout against an archive node will serve you better than paginating through REST for an afternoon.
API notes
Chain ID 137 on the Etherscan V2 API. Same key, same shape, same shared per-second limit across every chain you query.
Pagination discipline matters more here than anywhere else we cover. An address with a hundred thousand transactions returns in pages, and a naive loop will exhaust your daily allowance on a single address. Use startblock and endblock to narrow, and cache — historical blocks do not change.
The keyless alternatives worth knowing are Blockchair and 3xpl, both of which index Polygon and both of which send permissive CORS headers so they can be called from browser code. Our API comparison covers where each is the right answer.
Polygon PoS, zkEVM and the naming problem
"Polygon" refers to several distinct networks, and choosing the wrong explorer for the one you are on is a common and entirely understandable mistake.
Polygon PoS is the original sidechain, chain ID 137, and is what almost everyone means. It has its own validators and checkpoints to Ethereum.
Polygon zkEVM is a separate validity rollup with its own chain ID, its own bridge and its own explorer. Assets on one are not assets on the other, and a contract deployed to PoS does not exist on zkEVM.
There have also been various supporting chains and testnets over the years, each with its own tooling. The naming does not help: the marketing treats them as one product and the chains treat them as unrelated networks.
The practical check takes ten seconds. Look at the chain ID your wallet reports and confirm it matches the explorer you have open. If a transaction "does not exist", that mismatch is the first hypothesis to test — well before concluding that anything has gone wrong.
The same caution applies to bridges. Moving assets between PoS and zkEVM is a cross-chain operation with two transactions and two identifiers, exactly like moving between Ethereum and either of them. It is not an internal transfer, however similar the branding makes it look.
Our page on Base covers the rollup settlement model in more detail, and the distinction between a rollup and a sidechain is the thing worth carrying between the two pages.