Polygon added Besu as a supported configuration in its chain development kit on October 19, opening a path for institutions and consortia to run private chains wired into Agglayer. The setup is production-ready on Ethereum mainnet, with testnet and devnet options for teams that want to evaluate it first. It's aimed squarely at the crowd that wants its own validators and its own data, not a seat on a public rollup.
What those operators get is the standard Besu client plus QBFT consensus, with the Agglayer bridge connection baked in from genesis. They run their own validators, control account permissioning, and keep transaction data inside their private infrastructure.
Pessimistic proofs, not zero-knowledge
The bridge relies on pessimistic proofs. In plain terms, that limits how much a connected chain can pull out of the shared bridge, so a member chain that fails or gets compromised can't drain funds that belong to everyone else. The trade-off is explicit: the pessimistic proof does not verify the chain's internal state transitions. Execution stays under the private ledger's own controls.
Polygon is direct about who this isn't for. Institutions that need full zero-knowledge execution proofs are pointed to the CDK configuration on op-reth. The Besu path is pessimistic-only.
Settlement runs through a specific pipeline. Agglayer requests a pessimistic proof generated on the Succinct Prover Network. That proof is verified and settled on Ethereum before the bridge service processes the transfer.
Keeping validators off the public network
A dedicated RPC node carries the connection so validators don't have to sit on the public network. Operators need to add hostnames to that node's host allowlist — an easy step to miss and a hard one to debug.
The consortium option splits block production from certificate approval. Each member runs its own QBFT validator and keeps its validator key, and membership changes go through a validator vote. Polygon recommends four or more validators for testnet and mainnet. A single-validator devnet is fine for testing, but it stops if that one validator goes down.
Certificate approval uses a separate signer set: the AggchainECDSAMultisig contract requires M of N registered signers to approve each certificate. One member runs the proposing aggsender, while the rest run aggsender validators that check certificates against their own view of the chain before signing off.
Order matters in the signer list. The first address in the consensus contract's signer list has to be the aggsender address, or the aggsender simply refuses to send certificates.
The allowlist trap and a version floor
When an account allowlist is enabled, the aggoracle and ClaimTxManager addresses must be added before aggkit and the bridge service start. Every validator and RPC node has to use the same allowlist. Miss one node and the whole thing gets messy.
The documentation sets a hard floor at aggkit 0.9 or later. Earlier versions recompute block hashes in a way that never matches a QBFT block hash, which prevents certificate creation outright.
There's another quirk worth flagging. QBFT finalizes each block as it's produced, but Besu doesn't serve safe and finalized block tags. So every aggkit block-finality setting has to use LatestBlock.
Nothing here is a surprise for teams already running private EVM chains — it's plumbing, and plumbing is where deployments die. For institutions that wanted Agglayer connectivity without handing execution to a public network, the Besu route now exists as a documented, mainnet-ready option. The evaluation window is the testnet and devnet setups, and the open question is how many consortia actually want pessimistic proofs rather than waiting for the op-reth path to fit their needs.
