cloudparts

Besu

An Ethereum client in Java, formerly Hyperledger Besu, that runs a node on public Ethereum or a private, permissioned network of your own with proof-of-authority consensus.

LFDT · Graduated
Type
Open source
Foundation
LF Decentralized Trust, graduated. Part of the Linux Foundation
License
Apache 2.0
Facts checked
28 October 2026

What it is

Besu is an Ethereum execution client: it keeps the chain’s state, runs the Ethereum Virtual Machine (EVM) and serves the standard JSON-RPC API over HTTP and WebSocket, so the usual Ethereum tools (Solidity, Hardhat, Remix, web3j) work against it. On Ethereum Mainnet and public testnets such as Hoodi and Sepolia it is one of several interchangeable execution clients and must be paired with a proof-of-stake consensus client such as Teku. It stores state in RocksDB, by default in the Bonsai format, which keeps only recent state and needs about 1.14 TB for a snap-synced Mainnet node; the older Forest format suits archive nodes and grows to about 12 TB. Besu doesn’t manage keys itself; its docs point to Web3Signer for signing.

The same binary can start a private network with its own genesis file. There, validators use proof of authority instead of staking: QBFT or IBFT 2.0, both Byzantine fault tolerant with immediate finality, so a block never gets reorganised. Existing validators vote new ones in, at least four are needed to tolerate a faulty one, and the network stalls if more than a third go offline. Node and account permissioning come from local configuration files or plugins. Besu has been simplifying: version 25.6.0 (June 2025) removed private transactions through the Tessera transaction manager and smart-contract (onchain) permissioning, Clique is no longer supported, and proof of work and fast sync are being retired. Releases come roughly monthly and are numbered by year and month; the latest is 26.10.2 (October 26, 2026).

Why teams pick it

  • Real Ethereum: contracts, wallets and tooling built for the public chain run on a private Besu network, and the same client can join Mainnet
  • QBFT gives immediate finality with known validators, which suits a consortium that can’t wait for probabilistic confirmations
  • Apache 2.0, written in Java, with a plugin API for custom permissioning, storage and transaction selection without forking the client
  • A graduated LF Decentralized Trust project with maintainers from several organisations and frequent releases that keep up with Ethereum’s forks

Watch out for

  • No built-in privacy any more: on a private network every node sees every transaction, so confidential data needs a separate layer such as LFDT’s Paladin project
  • Moves fast and breaks things: features are removed between releases, the plugin API is being reorganised, and some database upgrades can’t be opened by an older Besu
  • A Mainnet node needs a consensus client alongside it and over a terabyte of fast disk, and the JVM needs tuning for memory
  • A BFT network with fewer than four validators gives no fault tolerance, and one that loses more than a third stops producing blocks

Alternatives

What all distributed ledgers have in common →Compare side by side →

How it fits with other technologies

Start a QBFT node, then vote in another validator · bash

# genesis.json (excerpt): QBFT with a 5-second block time
#   "config": { "chainId": 1337, "berlinBlock": 0,
#     "qbft": { "blockperiodseconds": 5, "epochlength": 30000,
#               "requesttimeoutseconds": 10 } }
besu --genesis-file=genesis.json --data-path=data \
  --rpc-http-enabled --rpc-http-api=ETH,NET,QBFT

# On each existing validator: propose adding a new one.
# It joins once more than half of the validators agree.
curl -X POST -H 'Content-Type: application/json' --data \
  '{"jsonrpc":"2.0","method":"qbft_proposeValidatorVote",
    "params":["0x42eb768f2244c8811c63729a21a3569731535f06",true],"id":1}' \
  http://127.0.0.1:8545

See it in a real stack

No architecture uses Besu yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2018–2026

Besu started as Pantheon, a Java Ethereum client that PegaSys, the protocol engineering team at ConsenSys, released in November 2018. On August 29, 2019 it joined Hyperledger as Hyperledger Besu, which its developers called “the first blockchain project submitted to Hyperledger that can operate on a public blockchain”. The announcement listed what it was built for: proof of work for Mainnet, proof-of-authority consensus (IBFT 2.0 and Clique) for consortium networks, node and account permissioning, and private transactions through a separate transaction manager. ConsenSys became a Premier Member of Hyperledger two weeks later, and on March 30, 2020 Besu graduated from incubation to Active status.

Ethereum’s move to proof of stake split each node into an execution client and a consensus client, and Besu became one of the execution clients. Its enterprise side went the other way. In September 2024 its maintainers announced they would sunset Tessera privacy, smart-contract permissioning, proof of work and fast sync, saying these features “have not kept pace with advancements in the Ethereum ecosystem” and that removing them would mean fewer bugs and faster development. Privacy and onchain permissioning were removed in 25.6.0 in June 2025.

When LF Decentralized Trust launched in September 2024, the project dropped the Hyperledger prefix and became simply Besu; its code now lives in the besu-eth GitHub organisation. It still describes itself as suited to enterprise private networks, and its LFDT page links it to Paladin, a separate project for private EVM transactions, and carries news of Besu’s role in DTCC’s tokenisation service.

Why it’s built this way

Written in Java
PegaSys aimed it at enterprises, where Java skills and tooling are common, and the Apache 2.0 licence lets them build on it freely.
One client for public and private chains
The same code can follow Mainnet and run a consortium network, so a private network keeps up with Ethereum’s EVM changes and tools instead of drifting into a fork.
Modular, with plugins
The 2019 announcement called Besu “designed to be as modular as possible”; a plugin API lets companies add permissioning or storage behaviour without maintaining their own fork.
Cut enterprise features that lagged
Privacy and onchain permissioning were costly to maintain and behind the rest of Ethereum, so the maintainers moved them to the application layer and kept the core small.

Timeline

  1. 2018

    PegaSys at ConsenSys launches Pantheon in November

  2. 2019

    Pantheon joins Hyperledger as Hyperledger Besu on August 29

  3. 2020

    Besu graduates from incubation to Active status on March 30

  4. 2024

    Maintainers announce the sunset of Tessera privacy in September; the project becomes Besu under LF Decentralized Trust

  5. 2025

    25.6.0 removes Tessera privacy and onchain permissioning in June

  6. 2026

    26.10 schedules the Amsterdam fork on the Hoodi testnet

Sources12 · facts checked 28 October 2026

Improve this page on GitHub