Bor: operating the official Polygon PoS node client

What Bor is and who operates it

Bor is the official Golang implementation of the Polygon PoS blockchain. It is a fork of geth and is EVM compatible up to the London fork. The repository is not archived and its last push was on 2026-10-15, with v2.10.3 released the same day. The project ships under the LGPL-3.0 license. Operators run Bor as validator, sentry, or archive nodes on Polygon Mainnet or the Amoy testnet. The minimum hardware list in the README calls for a CPU with 4 or more cores, 8 GB of RAM, 1 TB of free storage, and an 8 Mbit/s download link. The recommended profile is 8 or more cores, 16 GB or more of RAM, a high-performance SSD with at least 1 TB free, and 25 Mbit/s or faster download.

How Bor is structured and what traces it exposes

Bor builds a single binary named bor from cmd/cli/main.go, as the Makefile target shows. The consensus implementation lives under consensus/bor and the CLI under internal/cli. The go.mod file pins Go 1.26.9 and pulls in 0xPolygon/heimdall-v2, so Bor depends on Heimdall for the Polygon PoS consensus layer rather than reimplementing it. The README documents a Parity and OpenEthereum compatible trace namespace: trace_block, trace_transaction, trace_replayTransaction, trace_replayBlockTransactions, trace_call, and trace_callMany. These methods are disabled by default because they are expensive and require an archive node. Two trace limitations are stated explicitly. trace_call and trace_callMany still require the simulated sender to pass Bor's upfront gas balance check. trace_block omits the state-sync pseudo-transaction for blocks before Madhugiri (block 80,084,800 on mainnet), while post-Madhugiri blocks are fully supported. A vmTrace for a post-Madhugiri state-sync transaction reports an empty ops list because state-sync events execute outside the regular EVM opcode flow.

Installing Bor and running a first node

The packaging script is the easiest path. It accepts mainnet or amoy as the network and validator, sentry, or archive as the node type. It creates a bor user, installs the binary at /usr/bin/bor, writes config to /var/lib/bor, and registers a systemd service named bor.

curl -L https://raw.githubusercontent.com/0xPolygon/install/main/bor.sh | bash -s -- v2.0.0 <network> <node_type>

The example pins v2.0.0. Check the releases page for the latest stable version before running it. To build from source, install Go (version 1.19 or later) and a C compiler, then run:

make bor

Start Bor with one of the ideal config files shipped under packaging:

./build/bin/bor server --config ./packaging/templates/mainnet-v1/sentry/sentry/bor/config.toml

Build the full set of utilities with:

make all

Run the test suites with:

make test && make test-integration

Post v0.3.0, Bor uses a new CLI located at internal/cli. Flag usage stays close to the old CLI in cmd/geth, with a few notable changes, and the docs directory holds the flag usage guide and examples. The README points to docs/cli/default_config.toml for canonical TOML options.

Enabling traces without breaking the node

Enable the trace namespace with the rpc.enabletrace flag or the enabletrace key under jsonrpc in TOML.

bor server --config ./config.toml --rpc.enabletrace

[jsonrpc]
  enabletrace = true

Requirements: an archive node started with --gcmode archive, plus enough HTTP write timeout for deep blocks. The trace methods already use a 60s per-phase budget, while the HTTP response write timeout defaults to 30s and is configurable via TOML only.

[jsonrpc.timeouts]
  write = "60s"

Limitations and when Bor is the wrong choice

Bor is EVM compatible only up to the London fork, so workloads that depend on later EVM changes will not run as expected. Its trace namespace is disabled by default and is expensive, and even when enabled it carries the gaps described above: the upfront gas balance check for trace_call and trace_callMany, and the omitted state-sync pseudo-transaction on pre-Madhugiri blocks. The minimum storage requirement is 1 TB to sync mainnet, which rules out small disks. Bor is a Polygon PoS client, not an Ethereum mainnet client, so an Ethereum mainnet node needs a different client. The trace documentation compares Bor against Polygon Erigon, so teams whose workload is heavy historical tracing should evaluate Erigon as well rather than assuming Bor covers every trace case.

Maintenance, upgrades and licence implications

Maintenance status comes from the repository facts: not archived, last push on 2026-10-15, with recent releases v2.10.3 on 2026-10-15, v2.10.2 on 2026-09-30, and v2.10.2-beta5 on 2026-09-28. The project uses LGPL-3.0, a copyleft licence; linking and distribution obligations apply, so review with counsel before shipping Bor inside a proprietary product. Contribution rules require pull requests based on and opened against the develop branch, with PR titles prefixed by the packages they modify, for example "eth, rpc: make trace configs optional". Code must follow gofmt, and contributors are asked to run make test and make test-integration. For upgrades, check docs/cli/default_config.toml for canonical options, since the CLI changed post v0.3.0 and config keys can shift between releases.

Verdict: who should adopt Bor

Adopt Bor if you are operating a Polygon PoS validator, sentry, or archive node and can meet the 1 TB storage and multi-core CPU requirements. Do not adopt it for Ethereum mainnet workloads or for contracts that need EVM features beyond the London fork.

Editorial conclusion

Adopt Bor if you are operating a Polygon PoS validator, sentry, or archive node and can meet the 1 TB storage and multi-core CPU requirements. Do not adopt it for Ethereum mainnet workloads or for contracts that need EVM features beyond the London fork. Before upgrading, check docs/cli/default_config.toml for changed keys and run make test and make test-integration.

Frequently asked questions

Official sources

1. 0xPolygon/bor on GitHub
2. License: LGPL-3.0
3. Project website
4. README
5. Releases