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 whole timeline: a withdrawal cannot be completed on Ethereum until the checkpoint covering it has been submitted, which is why withdrawals take significantly longer than the two-second block time implies. PolygonScan has the checkpoint data. It does not connect it to the withdrawal experience anywhere a confused user would find it.
MATIC, POL, and the resulting confusion
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 annoying. 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.
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 you are wading through one. Internal transactions are on their own tab and are where contract-to-contract value movement appears; 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.
API notes
Chain ID 137 on the Etherscan V2 API. Same key, same shape, same shared rate limit:
GET https://api.etherscan.io/v2/api
?chainid=137&module=account&action=txlist
&address=0x...&startblock=0&endblock=99999999
&sort=desc&apikey=YOUR_KEYPay attention to pagination here more than on other chains. 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.
If you need heavy historical extraction, an explorer API is the wrong tool. Dune or a self-hosted Blockscout instance against an archive node will serve you better than paginating through a REST endpoint for an afternoon.
Verdict
PolygonScan is the default and there is no strong reason to fight that. It is dependable, it handles the volume, and the tooling is familiar.
Keep Blockscout in mind if you want open source, and OKLink if you want address labelling — Polygon has a lot of contract activity and knowing which contract belongs to which protocol saves time.
The two things to carry: checkpointing is what makes bridge withdrawals slow, and the POL rename means you must check contract addresses rather than token names. Neither is explained on the site, which is why they are explained here.
What our reference tests showed
We pointed our standard EVM reference set at Polygon and then added the thing this chain makes hard: an address with a very large transaction history.
The contract items behaved as expected. Verification, proxy resolution, the read and write tabs, revert reasons and the approval checker all worked identically to Ethereum, which is the correct result.
The high-volume address was the real test. We opened one carrying well over a hundred thousand transactions. The page loaded, pagination held, the date filter narrowed it usefully, and CSV export produced a file we could reconcile against. Several explorers we have used in the past simply time out on addresses like this.
The checkpoint test was less satisfying. The data is present — the checkpoint contract on Ethereum is visible, and the relationship can be established — but nothing on a transaction page tells you that a bridge withdrawal depends on it. We had to already know what to look for, which is the gap this review keeps returning to.