How Polygon PoS Validators Work: Heimdall and Bor

Polygon PoS runs on two layers. Bor, a Geth-based client, produces the blocks and executes EVM transactions. Heimdall, a CometBFT chain, runs validator consensus, picks who produces blocks and writes a checkpoint of Bor’s history to Ethereum about every 15 minutes (measured in October 2026). The staking contracts live on Ethereum, not on Polygon.

So a validator runs both clients, holds its stake on Ethereum and signs checkpoints with a separate signer key. This article walks through each piece in that order: layers, block production, checkpoints, finality, the validator set, penalties and the hardware. It stays with how the protocol works; for Polygon staking itself see the Polygon network page. Numbers marked as measured were read from public endpoints on 22 and 23 October 2026, and the last section shows the commands so you can repeat them.

Two layers: Bor and Heimdall

Polygon’s documentation splits the network into layers:

• Bor (execution layer). A set of block-producing nodes that execute EVM transactions. Bor is based on Go Ethereum (Geth), with Erigon also supported.
• Heimdall (consensus layer). A set of proof-of-stake nodes that monitor the staking contracts on Ethereum, validate Bor block data and submit periodic checkpoints to Ethereum mainnet.
• Ethereum layer. Contracts on Ethereum mainnet: the staking contracts, checkpoint storage and the bridge.

Heimdall v2 is a rewrite of the original Heimdall on CometBFT and the Cosmos SDK, specified in PIP-43, PIP-44 and PIP-62 (all Final). According to Polygon Labs it went live on mainnet in July 2025. The live node reports chain id heimdallv2-137 (read on 22 October 2026). Its blocks arrive about every 1.2 seconds (measured), and it adds custom modules for the Polygon-specific work: bor, checkpoint, milestone, stake, clerk, chainmanager and topup.

Heimdall learns about stake changes on Ethereum through a bridge processor. It relays events such as Staked, StakeUpdate, UnstakeInit and SignerUpdate, and Heimdall applies a change once more than two-thirds of validators, by voting power, confirm that it happened on Ethereum. That is why the stake lives on Ethereum while the validator set lives on Heimdall: the second follows the first.

Spans, sprints and block producers

Bor organises block production in two units:

• Sprint: 16 blocks. PIP-5 cut the length from 64 to 16 blocks. Today the sprint boundary matters mainly for state sync, where Bor commits pending records from Heimdall at the start of each sprint.
• Span: 6400 blocks, which is 400 sprints. At 1.5 seconds per block a span lasts 9600 seconds, about 2.7 hours. Heimdall’s bor/params endpoint returns sprint_duration 16 and span_duration 6400, and each of the last 24 spans on 22 October 2026 was exactly 6400 blocks long. The parameter is not a guarantee: one earlier span (id 15216) covered 7467 blocks, so read span boundaries from Heimdall instead of assuming them.

Since the Rio hardfork (mainnet, 8 October 2025) each span has exactly one selected producer that seals every block in it. This is the single-producer design introduced by PIP-64 and PIP-73. The producer is drawn from a small pool chosen by validator vote: each vote is weighted by the voting validator’s stake and by the candidate’s position in that validator’s ranked list. Polygon’s docs describe the pool as currently up to four producers. The live rotation matches: the last 24 spans (ids 15217 to 15240) used validators 91 to 94, one after another in order.

Validators that do not produce a span’s blocks still execute them. They use stateless block verification (PIP-72): they re-execute the transactions against state data supplied in a witness, so they do not need the full state stored locally.

If a producer stalls, Heimdall publishes a new span with another producer. Polygon’s changelog says the Ithaca upgrade (mainnet, 29 July 2026) lets Heimdall rotate a span on its own when the Bor head stops advancing past a threshold.

Block time

Bor’s block time is 1.5 seconds. On 22 and 23 October 2026 a 1000 block sample on two public endpoints took 1500 seconds. Because Bor timestamps are whole seconds, consecutive blocks alternate between 1 and 2 seconds apart.

The number has changed this year. It was 2 seconds until early May 2026 and 1.75 seconds from about 6 May (read from block timestamps). The Polygon docs changelog dates the move to 1.5 seconds to 3 June 2026.

Checkpoints to Ethereum

A Polygon checkpoint is a Merkle root of a contiguous range of Bor block hashes. Heimdall validators sign it and it is submitted to the RootChain contract on Ethereum. It is a different thing from the checkpoints in Ethereum’s own consensus, where two-thirds of validators attest to a Casper FFG checkpoint to justify it (see what a blockchain validator does). Here the word means a snapshot of Polygon’s history written to Ethereum.

Checkpoints exist to give Ethereum finality for cross-chain withdrawals and to provide proof of burn when assets exit Polygon. Transactions that stay on Polygon do not wait for one (see the finality section below).

The flow, as the docs describe it:

1. A validator proposes a checkpoint. Heimdall picks the proposer with CometBFT’s stake-weighted leader selection, so the role rotates.
2. Each validator checks the proposed root hash against its own Bor node and signs through vote extensions.
3. The approved checkpoint waits in a checkpoint buffer.
4. A validator submits it to Ethereum with the collected signatures. The submitter pays the Ethereum gas, so a signer address needs an ETH balance.
5. On Ethereum, the RootChain contract calls StakeManager.checkSignatures, which requires signatures worth more than two-thirds of the total stake.
6. Heimdall records an acknowledgement (MsgCpAck) once the checkpoint lands. If one is overdue, it sends a no-ack (MsgCpNoAck) and the proposer changes.

The multi-step design is deliberate. Submission can fail because of gas limits, network traffic or high gas fees, and the buffer and ack steps let the network retry.

How often

About every 15 minutes in October 2026 (measured). Over the last 100 gaps between checkpoints on Heimdall, ending at checkpoint 114881 (created at about 01:00 UTC on 23 October 2026), the average was 15.8 minutes. The gaps are not fixed: they ranged from about 3.5 to 43 minutes. Polygon’s validator docs give 15 to 20 minutes on average, which agrees with the measurement. The delegate page of the same docs says about 30 minutes, which does not.

Length varies too. The checkpoints sampled covered 256 to 1792 blocks, always a multiple of 256 and averaging about 630. The length is a governance-set parameter, not a fixed schedule, so plan around the cadence you measure rather than a constant in the contracts.

The RootChain contract stores each checkpoint under a header block id equal to the checkpoint number times 10000. The last section uses that to compare Ethereum with Heimdall.

Finality on Polygon PoS

Finality has two speeds. Milestones are the fast path. Checkpoints are the slow one.

A milestone is a short-range agreement among Heimdall validators. Each proposes up to 10 recent Bor block hashes, and once validators holding two-thirds of the voting power agree on a consecutive sequence, the milestone is final. Polygon’s docs put this at 2 to 5 seconds, and Polygon Labs described the Heimdall v2 upgrade as bringing finality to about 5 seconds, down from 1 to 2 minutes.

You can read the result over standard JSON-RPC. The docs recommend eth_getBlockByNumber with the finalized tag. When tested, finalized trailed latest by 1 to 3 blocks on publicnode and by 2 to 5 blocks on polygon.drpc.org, so a few seconds either way. The safe tag returns an error: the same request that returned latest and finalized answered safe block not found for safe.

Checkpoint finality, on Ethereum, is what a bridge withdrawal waits for.

The validator set: slots, stake and keys

Slots and entry

The StakeManager contract on Ethereum caps the validator set at 105. PIP-4 raised the cap from 100 to 105. On 22 October 2026 the contract reported 104 active validators, so one slot was open. Three sources agreed: the contract, Heimdall’s checkpoint overview and Polygon’s staking API.

New validators can join only when a slot is free, meaning an active validator unbonds or is removed for poor performance. Polygon’s documented route is to submit an application at the Polygon validators hub. The docs state that applying does not guarantee a slot, and PIP-39 scores applicants on stake, experience and expertise.

The minimum self-stake for a new validator is 100,000 POL. The chain enforces it through the StakeManager’s minDeposit value, set by PIP-70. An older docs page still quotes 10,000 POL, but the contract is what a staking transaction is checked against.

Owner key and signer key

A validator has two identities:

• Owner. The Ethereum address that holds the stake, receives rewards and manages delegation settings. It owns the validator’s staking NFT, so changing the owner means transferring that NFT. Keep this key off the node.
• Signer. The key that sits on the validator node. It signs Heimdall blocks and checkpoints, and it cannot manage staking, rewards or delegations. The owner can change it through the staking app or by calling updateSigner on the StakeManager.

The signer address needs funds in two places: ETH on Ethereum to submit checkpoints and POL on Heimdall, added through top-up transactions, to cover Heimdall fees. Polygon’s docs advise rotating keys at least once a year.

Commission and delegation

Each validator sets its own commission, from 0 to 100 percent. A change is subject to a cooldown of 80 checkpoints, which is roughly a day at the cadence measured in October 2026.

Delegated POL does not go to the validator. It is transferred to the StakeManager contract, and the delegator receives validator-specific ERC-20 share tokens at the pool’s exchange rate (buyVoucher). sellVoucher starts unbonding, which takes 80 checkpoints for validators and delegators alike. How long that is depends on the checkpoint cadence: roughly a day at the cadence measured in October 2026, but the delegate page quotes about 30 minutes per checkpoint, which would make it about 40 hours. Moving delegated stake from one validator to another is a single transaction with no unbonding period. On 22 October 2026 all 104 active validators accepted delegation.

For how staking providers work in general, see staking as a service.

Penalties: why slashing is off and what PIP-4 does instead

Slashing, a penalty that destroys part of a validator’s stake, is not active on Polygon PoS today. PIP-69 states that slashing is currently disabled for Polygon staking but could be enabled in the future. The StakeManager source in the pos-contracts repository (main branch, read 22 October 2026) has no slash function, and none of the 209 validators read from the contract has a non-zero jailTime.

What Polygon uses instead is the PIP-4 performance process, which works on a rolling monitoring period of 700 checkpoints, roughly a week:

1. A validator that signs fewer checkpoints than a benchmark set against the median enters Grace Period 1.
2. If it is still below the benchmark after 700 checkpoints, it gets a Notice of Deficiency and Grace Period 2.
3. If it is still below after another 700 checkpoints, it gets a Final Notice and is unstaked. The forced exit is a forceUnstake call on the StakeManager that only governance can make.

The benchmark is 98 percent of the median share of checkpoints signed by the validator set (a lower 95 percent applied during the first transition months). The process is live. On 22 October 2026 Polygon’s staking API listed 95 of the 104 active validators as healthy, 4 in the first grace period and 5 at final notice.

The consequence for operators is simple. Missing checkpoint signatures lowers your performance score, and a low score eventually costs you the slot.

Running a validator: sentry and validator nodes

Polygon’s docs describe two machines per validator:

• Sentry node. A Heimdall node and a Bor node, open to the public network. It is the entry point.
• Validator node. A Heimdall node and a Bor node, reachable only through the sentry and closed to everyone else. RabbitMQ runs here too, and the node needs an Ethereum RPC endpoint.

Both use the same hardware specification:

• RAM: 32 GB minimum, 64 GB recommended.
• CPU: 8 cores minimum, 16 recommended.
• Storage: 4 TB minimum, 6 TB recommended.
• Network: 1 Gbit/s.

The sentry opens 26656 over TCP for Heimdall peers and 30303 over TCP and UDP for Bor (UDP carries peer discovery). The validator should have no port reachable from the public internet. That is the docs’ headline rule for validator nodes. Its Bor config.toml lists the sentry as a static node and its Heimdall config uses the sentry as seed and persistent peer, which is why the sentry must be set up first.

Two more habits from the docs: run single-purpose nodes, so a validator never serves public RPC, and keep the signer funded on both layers. The validator duties that run automatically are block verification, checkpoint proposing and signing, and state sync. Uptime, daily checks, pruning and monitoring are yours. The general picture of what a validator node does is in blockchain validator node.

Check it yourself

All samples below use public endpoints and need only curl and Node.js (we ran them on Node 24). Swap in your own endpoint where you have one. Public endpoints rate-limit, and the outputs are from 23 October 2026.

Block time and finality on Bor. Save as bor.mjs and run node bor.mjs https://polygon-bor-rpc.publicnode.com:

const url = process.argv[2];
const rpc = async (method, params) => {
  const r = await fetch(url, {
    method: 'POST',
    headers: { 'content-type': 'application/json' },
    body: JSON.stringify({ jsonrpc: '2.0', id: 1, method, params }),
  });
  return (await r.json()).result;
};
const block = (tag) => rpc('eth_getBlockByNumber', [tag, false]);
const num = (hex) => parseInt(hex, 16);

const latest = await block('latest');
const n = num(latest.number);
const older = await block('0x' + (n - 1000).toString(16));
const finalized = await block('finalized');

console.log({
  latest: n,
  avgBlockTimeSec: (num(latest.timestamp) - num(older.timestamp)) / 1000,
  finalizedLagBlocks: n - num(finalized.number),
});

{ latest: 96008906, avgBlockTimeSec: 1.5, finalizedLagBlocks: 2 }

Latest checkpoint from Heimdall’s REST API:

curl -s https://heimdall-api.polygon.technology/checkpoints/latest
curl -s https://heimdall-api.polygon.technology/checkpoints/count

{"checkpoint":{"id":"114881","proposer":"0x9aa1e7971a94cbc400d95e593e82fb6e79fc99d8","start_block":"96006566","end_block":"96007333","root_hash":"Bc0dd1mFx+QX7FWSOmW8y1DnwWZojG4K5dc6ppOZ3R0=","bor_chain_id":"137","timestamp":"1792717203"}}
{"ack_count":"114881"}

The same number from Ethereum. 0xec7e4855 is the selector for currentHeaderBlock() on the RootChain proxy:

E=https://ethereum-rpc.publicnode.com
curl -s -X POST -H 'content-type: application/json' \
  --data '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x86E4Dc95c7FBdBf52e33D563BbDB00823894C287","data":"0xec7e4855"},"latest"]}' $E

The result 0x44797310 is 1148810000. Divide by 10000 and you get 114881, the same checkpoint Heimdall reports. As a control, calling the same contract with a made-up selector (0xdeadbeef) returns execution reverted, so a real answer means the call reached the function.

Validator slots from the StakeManager. 0x4fd101d7 is validatorThreshold() and 0x7f952d95 is currentValidatorSetSize():

STAKE=0x5e3Ef299fDDf15eAa0432E6e66473ace8c13D908
for data in 0x4fd101d7 0x7f952d95; do
  curl -s -X POST -H 'content-type: application/json' \
    --data "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"eth_call\",\"params\":[{\"to\":\"$STAKE\",\"data\":\"$data\"},\"latest\"]}" $E
done

The results end in 69 (105 slots) and 68 (104 active). When the second number matches the first, the set is full and a new validator must wait for someone to leave.

---

Sources & References

Sources opened on 22 and 23 October 2026. Contract reads and REST values are from public endpoints.

• Polygon Docs, Polygon Chain overview
• Polygon Docs, PoS architecture overview
• Polygon Docs, Bor introduction
• Polygon Docs, Heimdall v2 introduction
• Polygon Docs, Heimdall v2 checkpoints
• Polygon Docs, Heimdall v2 milestones
• Polygon Docs, Finality
• Polygon Docs, Becoming a validator
• Polygon Docs, Validator performance
• Polygon Docs, Change signer address
• Polygon Docs, Prerequisites
• Polygon Docs, Validator best practices
• Polygon Docs, StakeManager reference
• Polygon Docs, Delegation reference
• Polygon Docs, Delegate
• Polygon Docs, Changelog
• Polygon Labs, Polygon hits ~5 second fast finality in Heimdall v2 upgrade
• Polygon Improvement Proposals repository (PIP-4, PIP-5, PIP-39, PIP-43, PIP-44, PIP-62, PIP-64, PIP-69, PIP-70, PIP-72, PIP-73)
• Polygon pos-contracts repository (StakeManager and RootChain source)
• Polygon heimdall-v2 repository (x/stake/README.md and app/vext.go: stake events and the two-thirds voting power rule)
• Polygon staking API, validators
• Heimdall v2 public REST gateway

---

Work with Matrixed.Link

Matrixed.Link operates Chainlink oracle infrastructure, validator nodes and full-stack blockchain infrastructure for protocols and institutions that need institutional-grade reliability. Official Chainlink node operator running Data Feeds, CRE, SVR and Proof of Reserve. ISO/IEC 27001:2022 certified. AAA-rated provider on StakingRewards.

Contact Matrixed.Link to discuss validator and staking infrastructure for your protocol.