A Polygon Heimdall explorer shows you the consensus side of Polygon PoS: the checkpoints that commit batches of Polygon blocks to Ethereum and the validators who sign them. The live panel above reads Polygon's public Heimdall API every 30 seconds, so you can see the newest checkpoint, its Bor block range, who proposed it and how voting power is spread.
Most people never think about Heimdall until a withdrawal to Ethereum sits at "waiting for checkpoint" for forty minutes. Then it suddenly matters a lot. This page explains what the layer does, how to read the numbers, and where to dig deeper when a regular block explorer doesn't show you enough.
Quick answer
Heimdall is Polygon PoS's validator and consensus layer. It finalizes Bor blocks in about 5 seconds since the Heimdall v2 upgrade (July 2025) and, every few hundred blocks, submits a checkpoint to Ethereum. Withdrawals from the PoS bridge can only be claimed after the checkpoint covering your burn transaction is on Ethereum.
What Heimdall is and why Polygon PoS has two layers
Polygon PoS is split into two cooperating pieces. Bor is the execution layer: it produces blocks roughly every two seconds, runs the EVM and holds your balances. It's what you see when you look up a transaction on the live Polygon explorer or on PolygonScan. Heimdall is the layer underneath that manages the validator set, handles staking events coming from Ethereum, picks block producers and — its best-known job — bundles Bor blocks into checkpoints that are posted to Ethereum.
Think of Bor as the busy shop floor and Heimdall as the accounting office that periodically sends a signed summary to head office. The summary doesn't contain every transaction. It contains a Merkle root: a single hash that commits to a whole range of blocks. Anyone can later prove that a particular transaction was inside that range, which is exactly what the PoS bridge does when you exit funds to Ethereum.
This separation is also why a normal explorer page for a Polygon transaction looks almost identical to an Ethereum one. Bor is a fork of Geth, so blocks, receipts, logs and gas behave the Ethereum way. Heimdall's data lives elsewhere, behind its own API, which is why dedicated Heimdall views exist at all. If you want the bigger picture of how the PoS chain fits together, our Polygon PoS explorer guide covers the Bor side in depth.
Reading the live checkpoint card
The dark card at the top of the widget shows the most recent checkpoint that Heimdall has acknowledged. Here is what each field means and how we'd use it.
| Field | What it tells you |
|---|---|
| Checkpoint # | Sequential ID; +1 per accepted checkpoint |
| Bor block range | First and last Polygon block included |
| Submitted | When Heimdall recorded it (your local time) |
| Proposer | Validator signer address that proposed it |
| Total checkpoints | Acknowledged count from /checkpoints/count |
| Active validators | Size of the current validator set |
The Bor block range is the most practical number on the card. Suppose you burned USDC on Polygon to withdraw it to Ethereum and your burn transaction sits in block 94,414,000. If the latest checkpoint's range ends at 94,414,245, you're covered and can go claim. If it ends at 94,413,733, you wait for the next one. Grab your block number from any explorer — our transaction lookup shows it right under the status — and compare.
When we sampled the API on the morning of 25 September 2026, checkpoint 112,446 covered blocks 94,413,734 to 94,414,245 (512 blocks) and arrived 13 minutes after checkpoint 112,445, which covered 768 blocks. Over the previous six and a half hours, checkpoints came in about every 15 minutes on average, with ranges between 256 and 768 blocks. Treat those numbers as a snapshot, not a promise.
The proposer is a validator's signer address, not its owner wallet. It's the key the validator uses to sign on Heimdall and Bor. Paste it into PolygonScan or Etherscan and you'll often see a label, but not always.
root_hash Base64-encoded rather than as a 0x hex string. If you compare it with the value stored on Ethereum, decode it to hex first — otherwise it looks like a mismatch when it isn't.Polygon validators, staking and voting power
The right-hand column of the widget lists the active validator count and the top five validators by voting power. Voting power on Polygon PoS comes from staked POL — the validator's own stake plus everything delegated to it. The percentage we show is simply each validator's power divided by the total power of the set.
A few things worth knowing when you look at these numbers:
- The set is capped. Polygon PoS runs with a limited number of validator slots. On our check it held 105 active validators. New operators can only join when a slot frees up.
- Concentration is visible. On 25 September 2026 the largest validator held about 11.5% of total voting power, the second about 11%, and the top five together a little over 40%. That's the kind of detail a transaction explorer never shows you. Watch the top-five list if you care about decentralization; the bars make shifts obvious.
- Jailing happens. A validator that misses too many signatures can be jailed. The raw
/stake/validators-setresponse includes ajailedflag for each entry. - Signer ≠ owner. Rewards and stake belong to the owner address on Ethereum; the signer is an operational key.
Where to stake or delegate
Staking and delegation happen through the official Polygon staking dashboard, which talks to the staking contracts on Ethereum. That's also the friendliest place to browse validators by name, commission, uptime and checkpoint signing performance. Our widget is for a quick, neutral look; the dashboard is where you actually act. Staking POL carries risks, including slashing and lock-up periods when you unbond — read Polygon's documentation before delegating, and treat nothing here as financial advice.
If you still need POL to pay gas on Polygon, buy it on a regulated exchange that holds licences in several jurisdictions and lets you withdraw directly to the Polygon network — check that the withdrawal network says Polygon PoS, not Ethereum, before you confirm.
Heimdall v2: CometBFT and 5-second finality
On 10 July 2025 Polygon activated the Heimdall v2 hard fork. Under the hood, Heimdall moved from a heavily modified old Tendermint fork to CometBFT with Cosmos SDK v0.50. For users, the headline was finality: deterministic finality on Polygon PoS dropped to about 5 seconds, compared with roughly one to one and a half minutes before.
Checkpoint #1 recorded on mainnet (the API still serves it).
POL replaces MATIC as the gas and staking token.
Heimdall v2 goes live: CometBFT, Cosmos SDK v0.50, ~5 s finality. The Bhilai hard fork lands the same month.
Rio upgrade introduces validator-elected block producers and stateless validation.
Why does finality matter if blocks already appear every two seconds? Because a block you can see isn't necessarily a block that can't be reorganized. Before Heimdall v2, exchanges and payment processors often waited for many confirmations on Polygon to be safe. With fast deterministic finality, a payment is settled within seconds in a way that doesn't depend on waiting for dozens of blocks. Heimdall achieves this with milestones: lightweight finality markers agreed by validators far more often than checkpoints. The public API exposes them at /milestones/latest.
Checkpoints still exist and still matter, because milestones finalize blocks on Polygon while checkpoints are what Ethereum contracts see. The two are complementary: milestones for speed on Polygon, checkpoints for proofs on Ethereum.
The v2 migration also changed the API. Heimdall's chain ID became heimdallv2-137, some endpoint paths moved, and response shapes changed (the Base64 hashes mentioned above, stringified numbers everywhere). If a script written in 2024 suddenly breaks, that's the first thing to check.
How to explore checkpoints and validators yourself
You have three good options, depending on how deep you want to go.
1. The widget on this page. Fastest way to answer "has the checkpoint I need arrived yet?" It refreshes every 30 seconds while the tab is visible and needs no wallet or account.
2. The Polygon staking dashboard. Best for browsing validators with human-readable names, commission rates and performance history, and for seeing checkpoint history in a UI.
3. The Heimdall REST API. Best when you want raw data or automation. We tested every endpoint below on 25 September 2026; all returned JSON without an API key and with CORS open, so you can call them straight from a browser.
| Endpoint | Returns |
|---|---|
/checkpoints/latest | Newest acknowledged checkpoint |
/checkpoints/count | Total acknowledged checkpoints |
/checkpoints/{id} | One checkpoint by number |
/milestones/latest | Latest finality milestone |
/stake/validators-set | Full active set with voting power |
/stake/validator/{id} | One validator by ID |
/stake/total-power | Sum of voting power |
/chainmanager/params | Contract addresses and confirmations |
The base URL is https://heimdall-api.polygon.technology. A quick test from your terminal:
curl -s https://heimdall-api.polygon.technology/checkpoints/latest{"checkpoint":{"id":"112446","proposer":"0x67b94473d81d0cd00849d563c94d0432ac988b49","start_block":"94413734","end_block":"94414245","root_hash":"TLQn3KmXkdF7xAh2JUzPfKDaQINMkturSfXb/9fUW20=","bor_chain_id":"137","timestamp":"1790327459"}}Numbers come back as strings, and timestamp is Unix seconds. Note the path is /stake/validator/{id} (singular); the plural form we tried returned "Not Implemented". For a wider comparison of Polygon data APIs — Blockscout, Etherscan API V2 and public RPC nodes — see our Polygon explorer API guide. Official background lives in the Polygon PoS documentation.
Why checkpoints matter for withdrawals and finality
Here's where Heimdall stops being abstract. The Polygon PoS bridge is asymmetric:
- Deposits (Ethereum → Polygon) don't wait for checkpoints. Heimdall validators watch Ethereum and relay the deposit through a mechanism called state sync. The public API showed over 3.2 million state-sync event records on our check. Deposits typically land in about 7–8 minutes.
- Withdrawals (Polygon → Ethereum) do wait. You burn tokens on Polygon, then wait until a checkpoint covering that burn block is submitted to Ethereum, then send an exit (claim) transaction on Ethereum that proves your burn against the checkpoint root. That wait is commonly 30–60 minutes or more, and historically could stretch to about three hours.
Every PoS bridge withdrawal needs a checkpoint on Ethereum first, then your own claim transaction there.
So when a wallet or the Polygon Portal says "waiting for checkpoint," compare your burn transaction's block number with the Bor range in the widget. No amount of refreshing or extra gas will speed it up; the claim simply can't be proven until that range is on Ethereum. Our Polygon bridge explorer walks through tracking both sides of a bridge transfer, and if your issue is a transaction that never confirmed on Polygon in the first place, the mempool page is the better place to start.
For everyday payments inside Polygon — sending USDT to a friend, paying a merchant — checkpoints are irrelevant. Heimdall's fast finality means your transfer is settled within seconds. Checkpoints only come into play when something has to be proven on Ethereum.
Limits of Heimdall data (and what we recommend)
A few honest caveats from testing. The public API is a shared gateway: it has been reliable in our tests, but it isn't a service-level guarantee, and it may throttle bursts. Response formats changed once already with v2 and could change again. And Heimdall data won't tell you anything about individual user transactions — for those you need a Bor-side explorer.
Our practical recommendation: use this page to check checkpoint progress and validator distribution, use a full explorer such as PolygonScan or Blockscout for transaction detail (we compare them in our ranking of the best Polygon explorers), and use the staking dashboard for anything involving your POL stake. That combination covers every question we've been asked about Polygon's consensus layer so far.