# Bor: operating the official Polygon PoS node client

> Bor is the official Go implementation of the Polygon PoS blockchain, a geth fork that stays EVM compatible up to the London fork. This guide covers what it does, how to install and run it, how to enable its trace namespace, and where its limits bite.

**0xPolygon/bor** — Official repository for the Polygon Blockchain

- Repository: https://github.com/0xPolygon/bor
- Website: https://polygon.technology/
- Stars: 1,107 · Forks: 623
- Language: Go
- License: LGPL-3.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/0xpolygon-bor

## 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.

```shell
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:

```shell
make bor
```

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

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

Build the full set of utilities with:

```shell
make all
```

Run the test suites with:

```shell
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.

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

```toml
[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.

```toml
[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.

## 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.

## FAQ

### What is Bor used for?

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, and operators run it as validator, sentry, or archive nodes.

### How do I install Bor?

Use the packaging script with a version, network, and node type, or build from source with make bor after installing Go 1.19 or later and a C compiler. Start it with ./build/bin/bor server and a config file from the packaging directory.

### Does Bor support Ethereum trace methods?

Bor includes a Parity-compatible trace namespace, but those methods are disabled by default and require an archive node. Enable them with --rpc.enabletrace or enabletrace = true under [jsonrpc] in TOML.

## Sources

- [0xPolygon/bor on GitHub](https://github.com/0xPolygon/bor)
- [License: LGPL-3.0](https://github.com/0xPolygon/bor/blob/develop/LICENSE)
- [Project website](https://polygon.technology/)
- [README](https://github.com/0xPolygon/bor/blob/develop/README.md)
- [Releases](https://github.com/0xPolygon/bor/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/0xpolygon-bor