Running your own Polygon node: infrastructure for prediction markets

Running a Polygon node yourself has historically been a commitment. Polygon PoS doesn’t run a single client the way Bitcoin, TRON, or Solana do — it runs two, paired together. Bor handles execution (it’s a modified go-ethereum client that produces and executes blocks), and Heimdall handles consensus — a Cosmos-SDK-based layer that manages the validator set, produces checkpoints, and commits them to Ethereum for finality.

You don’t run one binary and size one box; you run two services that have to stay in version lockstep, plus a dependency neither Bitcoin, TRON, nor Solana has: Heimdall needs its own Ethereum L1 RPC endpoint to track checkpoints, so “run a Polygon node” has always secretly meant “run a Polygon node and keep an Ethereum endpoint pointed at it.“

Teams that needed direct, verifiable access to Polygon state took on that two-client, cross-chain-dependency stack because the alternative — trusting a third party’s view of state you were settling real value against — wasn’t acceptable. Teams without that requirement rented an RPC endpoint and moved on.

The operational math has shifted. What made self-hosting Polygon a project was rarely Bor or Heimdall individually — both are mature, actively maintained clients with years of mainnet hardening. The hard part was everything around them: sizing hardware for two coordinated services, keeping both on compatible versions through Polygon’s active hard fork cadence, wiring up and maintaining the external Ethereum dependency, and monitoring checkpoint health rather than just block height. Chainstack Self-Hosted now supports Polygon PoS, which means that operational layer becomes software you consume rather than a stack you assemble yourself.

This piece is about who actually benefits from running their own Polygon node, what that looks like day-to-day, and how the newer, Self-Hosted answer compares to building it yourself.

Why running a Polygon node used to be a project

Bor and Heimdall aren’t two independent options — they’re a pair. Bor is the execution layer: it produces blocks, executes transactions, and exposes the standard Ethereum-style JSON-RPC surface every EVM tool already speaks. Heimdall is the consensus layer: a separate Cosmos-SDK/Tendermint-family process that tracks the PoS validator set, aggregates Bor block spans into checkpoints, and periodically commits those checkpoints to a contract on Ethereum — which is where Polygon’s real finality actually comes from. Run Bor without Heimdall and you have an execution client with no consensus input. Run them on mismatched versions during a hard fork window and you risk a node that silently disagrees with the network. When you run your own node, you get the same feature set Polygon’s own infrastructure operators do:

• The full Bor JSON-RPC surface against your own state — balances, contract state, transaction and block history, logs and events — with no rate-limit ceiling beyond your own hardware.
• WebSocket subscriptions for real-time new-block and log/event feeds, which matters anywhere your application reacts to on-chain events rather than polling for them.
• Direct transaction submission with full control over gas pricing, instead of routing through a shared provider’s mempool policy during congestion.
• Independent verification of balances and contract state. For anyone settling value or custody-adjacent logic against Polygon state, the answer to “how do you verify this?” is “we query our own node” — not “we trust a third party’s explorer.”

Unlocking that on your own infrastructure meant building the ops layer around the Bor/Heimdall pair yourself: sizing hardware for two coordinated services rather than one, bootstrapping Heimdall’s own chain state alongside Bor’s, standing up and maintaining an Ethereum L1 endpoint purely so Heimdall could track checkpoints, and staying current through a hard fork cadence that has shipped several major upgrades in the past 18 months. That’s the setup burden this article is really about — and the teams that took it on did so for specific, nameable reasons.

Who actually runs their own Polygon node, and why

• Prediction markets and high-frequency on-chain settlement. Polymarket is why Polygon data needs to be load-bearing infrastructure, not a rented API call: the platform has processed activity across 214,735+ markets for 2.4 million traders, with roughly $62 billion in cumulative volume, all settling on-chain through the CTF Exchange contract’s OrderFilled event. A market-making bot there is watching OrderFilled events, holding a live WebSocket order-book feed, and submitting transactions — all at once, and public endpoints throttle exactly that combination: rate limits and shared-tier latency show up as missed fills and stale order books. That’s a real cost on a chain processing about 110 TPS at $0.002 per transaction, with Bor blocks every 2 seconds and L1 finality roughly every 30 minutes. (See Chainstack’s guide to the Polymarket API and how to build a Polymarket trading bot.)
• Stablecoin and payments platforms. Polygon overtook BNB Chain in Q1 2026 to lead USD-stablecoin transaction volume with roughly a 34.5% share, and payment volumes on the network grew over 400% year-over-year. Stripe settles stablecoin payments to USDC on Polygon (alongside Ethereum and Solana), and Meta began routing creator payouts in USDC on Polygon and Solana through Stripe in April 2026. Visa named Polygon in its expanded stablecoin settlement pilot, which hit a $7 billion annualized run rate in the same period. Platforms moving that kind of volume verify balances against their own infrastructure — the same reason a TRON or Solana stablecoin processor does.
• DeFi protocols. Aave, the largest lending protocol on Polygon by TVL, is representative of the pattern: on-chain lending and swap logic that reprices or liquidates based on real-time state can’t tolerate a shared provider’s rate limits or latency during volatility — a delayed price update or a throttled liquidation call is a direct loss, not an inconvenience.
• Compliance and analytics platforms. Chainalysis and Elliptic run infrastructure against Polygon the same way they do for every major chain they cover — serving chain data as a compliance product means full, direct, redundant access, not depending on someone else’s node.

At a glance:

Audience	Use case	What running your own unlocks	Examples
Prediction markets & on-chain settlement	High-frequency order settlement, event monitoring, execution	Reliable OrderFilled event streams, WebSocket feeds, and tx submission without shared rate limits	Polymarket
Stablecoin & payments platforms	Settle USDC/stablecoin transfers and payouts at volume	Independent verification of balances and confirmations	Stripe, Meta creator payouts, Visa stablecoin settlement pilot
DeFi protocols	Lending, swaps, and on-chain logic tied to real-time state	Real-time account/contract state without shared-tier latency	Aave
Compliance & analytics	Transaction tracing and monitoring	Full, direct, redundant chain access	Chainalysis, Elliptic

The pattern across all of these: when Polygon data is load-bearing for your business — order settlement, payment confirmation, on-chain lending logic, compliance monitoring — you don’t rent it.

What running your own actually costs

• Initial sync. Polygon Mainnet doesn’t ship with a snapshot preset on Chainstack Self-Hosted — it syncs the conventional way, from genesis. In the wider ecosystem, a from-scratch sync (even using torrent-distributed snapshots) commonly takes anywhere from a few days to several weeks depending on client and hardware, against three to four days when pulling a recent third-party snapshot. Plan the initial sync window accordingly rather than assuming it behaves like Amoy.
• Storage growth. A Polygon Mainnet full node runs into multiple terabytes of state — Chainstack’s own Mainnet deployment provisions around 5.5 TB. Polygon’s Rio upgrade introduced witness-based stateless validation specifically to reduce the growth rate of that footprint going forward, but the existing state is already large and only grows from here.
• Updates. Polygon PoS ships hard forks on an active cadence, not a rare one: Bhilai (July 2025, raised the block gas limit and pushed throughput past 1,000 TPS), Heimdall v2 (mid-2025, replaced Heimdall’s consensus internals with CometBFT and Cosmos SDK v0.50, cutting finality from 1–2 minutes to roughly 5 seconds and adding EIP-7702 account abstraction), Rio (October 8, 2025, targeting 5,000 TPS via a validator-elected block producer model and stateless validation, effectively eliminating reorgs), Lisovo (March 4, 2026, introduced Dynamic Gas Target, followed by a 120M gas limit increase on March 23), and Giugliano (April 8, 2026, faster block-availability signaling and EIP-1559-style fee data in block headers). That’s four major upgrades inside roughly nine months, and because Bor and Heimdall version together, an upgrade means redeploying both clients in sync, not just bumping one binary.
• Monitoring and reliability. A Polygon node has two things to watch, not one: Bor’s block production and sync state, and Heimdall’s checkpoint submission health. A Bor node that looks perfectly synced can still be sitting behind a Heimdall instance that’s stopped submitting checkpoints to Ethereum — and because Heimdall’s checkpoint flow depends on your supplied Ethereum L1 endpoint, an outage or rate limit on that upstream endpoint becomes a Polygon finality problem, not just an Ethereum one.
• The “set it and forget it” myth. Plenty of Bor/Heimdall pairs run for stretches without intervention. They also drift the moment one client falls out of version lockstep with the other during a fork window, or the external Ethereum endpoint Heimdall depends on degrades quietly. For evaluation, that’s tolerable. For anything settlement- or payout-adjacent, it’s a two-client, two-dependency failure surface that’s easy to underestimate going in.

What changed: Chainstack Self-Hosted now supports Polygon

The historical reason teams reached for managed RPC over self-hosting Polygon wasn’t a preference for managed RPC — it was that sizing and running a paired execution/consensus stack, wiring up an external Ethereum dependency, and staying current through Polygon’s fork cadence was overhead most teams couldn’t justify unless the workload demanded it.

Chainstack Self-Hosted is what happens when you separate “own the node” from “build the operational stack around it.” Self-Hosted now supports Polygon PoS on Mainnet and the Amoy testnet, with the same deployment workflow as the rest of the platform: pick the protocol, pick the network, deploy (Supported deployments).

Mainnet runs Bor v2.8.3 paired with Heimdall v0.9.0, on 12 vCPU, 64 GiB RAM — split across the two clients — and roughly 5.5 TB of storage. Amoy testnet runs Bor v2.10.0 with Heimdall v0.11.0, on a lighter 6 vCPU, 24 GiB RAM, and 170 GB of storage. Here’s the asymmetry worth being upfront about: Amoy bootstraps from a pre-built snapshot — provision roughly 2× the steady-state storage during deploy, since the compressed archive and the extracted state briefly coexist on disk — but Mainnet does not. Mainnet syncs the conventional way, from genesis. If you’re deploying Mainnet, plan your initial sync window as a real sync, not a snapshot restore.

Polygon PoS also requires an Ethereum Layer 1 RPC endpoint that you supply. Heimdall uses it to track and validate checkpoints committed to Ethereum — without it, Heimdall has no way to follow Polygon’s actual finality layer. This is the same category of prerequisite that OP Stack chains on this platform carry: it’s not optional, it’s not provided for you, and an unreliable or rate-limited L1 endpoint becomes a Polygon problem, not just an Ethereum one. Have that endpoint ready before you deploy.

The exposed surface is Bor’s standard HTTP JSON-RPC on port 8545 and WebSocket JSON-RPC on port 8546, plus Heimdall’s REST API (Cosmos LCD) on port 1317. Bor’s P2P port (30303) and Heimdall’s CometBFT RPC (26657) and P2P (26656) ports are internal only and not exposed.

• Mainnet syncs without a snapshot; Amoy bootstraps from one. Size your deploy timeline for whichever network you’re actually running, not the other one.
• What you get is Kubernetes-level self-healing: if the node pod crashes, the deployment automatically restarts it and resumes from its last state on the persistent volume.
• Bor and Heimdall version upgrades still require you to redeploy the node yourself — Self-Hosted doesn’t currently auto-update client versions for you, which matters more on Polygon than on slower-moving chains given the fork cadence above.
• Multi-endpoint failover to a Chainstack-managed Polygon endpoint is planned but not yet shipped, the same status it has across the rest of Self-Hosted (Self-Hosted FAQ).
• You still own the node. The data never leaves your perimeter. You can point any Bor-compatible RPC client at it and query it like any other Polygon JSON-RPC endpoint — you just didn’t build the deployment and monitoring stack around it yourself.

When to self-host Polygon, and when not to

The decision isn’t religious. It’s a workload question.

Run your own Polygon node if:

• Your application makes more than a few hundred thousand RPC calls a day. Managed RPC pricing scales with call volume; your own node runs at a flat hardware cost regardless of throughput.
• You’re settling trades, orders, or payments where event delivery and confirmation latency directly affect outcomes.
• You process stablecoin or payment volume at scale and need independently verifiable balances and confirmations.
• You’re building a DeFi protocol, indexer, or analytics platform whose logic depends on real-time on-chain state.
• Compliance, audit, or regulatory frameworks require infrastructure control over how you access and verify chain data.

Reach for managed Chainstack Polygon instead if:

• You want to avoid the hardware cost and upfront commitment of Polygon’s paired-client infrastructure. 12+ vCPU, 64+ GiB RAM, and ~5.5 TB of storage split across two clients is real capital before you’ve served a single request; Chainstack Polygon nodes skip that entirely.
• You’re running at low-to-moderate volume in general — a production workload that doesn’t yet justify owning dedicated hardware, or you’re still learning and prototyping.
• You’d rather not maintain an Ethereum L1 endpoint as a standing prerequisite just to keep Heimdall’s checkpoint tracking healthy.

The middle ground — production workloads that wanted their own Polygon node without committing to sourcing and babysitting a two-client, cross-chain-dependent stack themselves — used to have no clean answer. DIY self-hosting worked, but the hardware research, the Bor/Heimdall version coordination, and the standing Ethereum endpoint dependency was itself a quarter of DevOps work. Chainstack Self-Hosted is what removes that barrier: your infrastructure, none of the setup marathon.

If your Polygon workload is heading toward “load-bearing for the business” — and on a chain settling billions of dollars in prediction-market trades and a growing share of the industry’s stablecoin payment volume, that threshold arrives faster than most teams expect — running your own node was always the right answer. What’s new is that the path from “I should probably do this” to “it’s deployed and monitored” doesn’t require becoming a Bor/Heimdall specialist first.

FAQ

Additional resources

Chainstack Self-Hosted documentation:

• Introduction to Chainstack Self-Hosted
• Supported clients and protocols
• System requirements
• Quick start
• Self-Hosted FAQ

External:

• Bor GitHub repository (Polygon Labs)
• Heimdall v2 GitHub repository (Polygon Labs)
• Giugliano upgrade overview (Polygon)

Related reading — Running your own node:

• Running your own Solana node
• Running your own Bitcoin node
• Running your own TRON node
• Running your own Base node