Skip to main content
CDK Besu runs a Hyperledger Besu chain with QBFT consensus (Besu’s Byzantine fault tolerant proof-of-authority consensus) and connects it to Agglayer. It is the Besu-based alternative to the OP Stack execution clients, op-geth and op-reth, and fits chains where a known set of validators operates a private ledger. The step-by-step deployment procedure is maintained in the public 0xPolygon/cdk-besu runbook. This page explains what the runbook deploys, how it differs from CDK op-reth, and which runbook chapter covers each step.

​
Scope

The cdk-besu runbook covers one deployment path: sovereign mode, secured by pessimistic proofs, with the AggchainECDSAMultisig consensus contract. It targets devnets, testnets, and production networks that settle on Sepolia or Ethereum mainnet, and includes an optional configuration for a chain operated jointly by a consortium.
The runbook creates a new chain with the Agglayer bridge and Global Exit Root (GER) contracts in its genesis. Connecting an existing chain with its own history follows the Agglayer Outpost path, which the runbook does not cover.

​
Security model

The pessimistic proof protects the shared bridge. It proves that the chain cannot withdraw more than it deposited, which caps the damage a faulty or compromised chain can do to the rest of the Agglayer network. The pessimistic proof does not prove the chain’s internal state transitions, and a CDK Besu chain posts no transaction data to L1. The chain’s state lives on the operator’s validators. For a private ledger this is the intended design; confirm it matches your requirements before you deploy.

​
Architecture

A CDK Besu chain combines Besu nodes with the same Agglayer components used by other CDK chains: aggkit and the bridge service also read GER and bridge events from L1 and the Besu RPC node continuously. Step 4 applies only to the consortium configuration.

​
How CDK Besu differs from CDK op-reth

​
Before you deploy

These Besu-specific requirements affect planning. The runbook explains each one in detail.
  • Use aggkit 0.9 or later. Earlier versions recompute L2 block hashes in a way that never matches a QBFT block hash, so aggkit never builds a certificate.
  • Track the latest block. QBFT finalizes each block when it is produced, and Besu returns error -39001 for the safe and finalized tags. Set every aggkit block finality setting to LatestBlock.
  • Size the validator set for fault tolerance. QBFT tolerates f faulty validators with at least 3f + 1 validators. A single validator works for devnets, but one failure halts the chain; use four or more validators for testnet and mainnet.
  • Run a separate RPC node. aggkit, the bridge service, and users connect to the RPC node. Add their hostnames to the node’s --host-allowlist.
  • Register the aggsender as the first signer. During rollup initialization, the first entry in the AggchainECDSAMultisig signer list must be the aggsender address, or the aggsender refuses to send certificates.
  • Apply account permissioning on every node. If you enable a Besu account allowlist, add the aggoracle and ClaimTxManager addresses before starting aggkit and the bridge service, and apply the same allowlist on every validator and RPC node.
The runbook pins the tested versions of Besu, agglayer-contracts, aggkit, and zkevm-bridge-service in its Prerequisites chapter. Keep your deployment in step with those versions.

​
Consortium configuration

When several organizations operate one chain, the runbook uses two independent controls so that no single member can produce blocks or settle a certificate alone:
  • Shared block production. Each member runs its own QBFT validator and keeps its own validator key. Membership changes go through a QBFT validator vote.
  • Shared certificate approval. AggchainECDSAMultisig requires M of N registered signers to approve each certificate. One member runs the proposing aggsender, and each other member runs an aggsender validator that checks the certificate against its own view of the chain.
See Consortium Configuration for the key handling, signer configuration, permissioning, and operational agreements members need before launch.

​
Runbook chapters

​
Resources

cdk-besu runbook

The canonical step-by-step deployment guide for CDK Besu chains.

Integration flow

The end-to-end sequence from intake to a live chain on Agglayer.

Environments

Agglayer endpoints and L1 contract addresses for Bali, Cardona, and Mainnet.

Besu QBFT documentation

Upstream reference for QBFT genesis options and validator management.