When a bank or market infrastructure provider plans a new blockchain network, Besu is often the first client on the list. It’s open source, familiar to enterprise security teams and built for networks where a known set of institutions runs the validators.
The tradeoff has been that a private Besu chain starts life on its own. Inside the network, assets move exactly as designed. Getting them to a counterparty or a pool of liquidity on another chain has usually meant a separate integration project for each connection, often through a bridge that verifies transfers with a committee of signers, which brings its own round of risk review.
Today, Polygon CDK adds Besu as a supported configuration. With Polygon CDK Besu, a bank or financial institution can launch a private Besu chain running QBFT consensus, natively connected to Agglayer from its first block. Agglayer upgrades Besu with ZK bridge security. The chain runs the standard Besu client, it can move assets to and from any other chain connected to Agglayer, and every transfer settles against a zero-knowledge proof on Ethereum. The deployment runbook is public on GitHub if you want to see exactly how it works.
Besu joins Polygon CDK OP Stack as a way to build a CDK chain, so institutions can pick the client that fits their team and their requirements and get the same Agglayer connection either way.
What Agglayer adds to stock Besu
With Agglayer, there’s no validator judgment to manipulate, no RPC feed to poison. The signers that get compromised in every other bridge hack don’t exist in this architecture, because the architecture doesn’t need them.
Layered on top of that, Agglayer enforces what we call pessimistic proofs. Think of it as the bridge’s accountant who trusts nobody and verifies everything.
Every chain connected to Agglayer has a running balance of what it has received and what it has sent. Before any withdrawal finalizes, the math has to add up. Any other outcome, including if a chain tries to withdraw more of an asset than it actually has, the proof defaults to failure and nothing moves. Strict firewalls between chains.
What you get when you launch with Polygon CDK Besu
A private network is valuable because of who’s inside it. It becomes a lot more valuable when what’s inside can reach what’s outside, on the institution’s own terms. Polygon CDK Besu is built so you don’t have to choose between the two.
- Your chain, your rules. Your institution, or your consortium, runs the QBFT validators and decides who can transact through Besu’s account permissioning. Transaction data stays in your private infrastructure and isn’t posted to Ethereum.
- ZK bridge security. Every transfer settles against a proof, which caps your exposure to any other connected chain. If a chain on the other side is compromised, it can’t reach the funds on yours.
- Connected from day one. Assets can move between your chain and every other connected chain, including public networks where stablecoin and tokenized-asset liquidity already sits.
- One version of each asset. A token bridged through Agglayer has a single canonical version on every connected chain, rather than a different wrapper for each bridge it crosses. Liquidity stays in one pool, and your treasury and operations teams have one asset to account for.
- No rent. There’s no revenue share owed to Polygon on the activity your network generates.
What this looks like for a bank
Picture a bank launching a network to issue tokenized deposits to its corporate treasury clients. On CDK Besu, the bank’s own validators run the chain, its permissioning decides which clients can transact on the network, and clients move cash between their entities around the clock.
Some time later, a client wants to put part of that balance into a tokenized money market fund issued on another chain. On an isolated network, that would mean redeeming the deposit, moving cash through traditional rails and buying back in on the other side, across business days. Because the bank’s chain was connected to Agglayer from the start, the deposit token can move to the fund’s chain directly. The transfer settles against a proof, the token arrives as the same canonical asset, and it can come back the same way.
The same pattern fits collateral that needs to move between venues, settlement between two institutions on different networks, and a consortium that wants its members’ chains to work together without each pair building its own bridge.
Why Besu, Polygon CDK and Agglayer work better together
Each piece brings something the others don’t, and together they give an institution a chain it can trust that doesn’t sit on its own.
A ledger your security and compliance teams already trust, with Besu. It’s governed in the open under the Linux Foundation, and DTCC’s collateral platform, Clearstream’s digital securities infrastructure, Citi Token Services, Project Agorá and Swift’s shared ledger all run on it. The Linux Foundation counts 80 institutional platforms built on its decentralized trust technologies.
A chain you can launch and run, with Polygon CDK. CDK brings the deployment runbook, the bridge contracts written into genesis, the services that keep the chain in sync, and a consortium setup in which no single member can act alone.
Reach to other chains and their liquidity, with Agglayer. Stock Besu stops at your network’s edge. Your chain connects to every other chain on Agglayer, and each transfer is settled against a proof rather than a committee’s signatures. The Linux Foundation’s own report makes the point that choosing the ledger has become the easy part, and that interoperability is near the top of what institutions need now. With CDK Besu, that connection comes built in.
Choosing your CDK configuration
CDK Besu and CDK OP Stack both connect to Agglayer natively. The difference is in how the chain runs underneath, so the right choice depends on what your team already knows and what the use case needs.
| CDK Besu | CDK OP Stack | |
|---|---|---|
| Best fit | Private ledgers run by a known set of validators, including consortiums | Chains that want the OP Stack ecosystem and the option of full execution proofs |
| Execution and consensus | Standard Besu client, QBFT consensus with immediate finality | op-reth with op-node |
| Transaction data on Ethereum | None. Transaction data stays in your private infrastructure | Posted to Ethereum |
| Security to Agglayer | Pessimistic proof | Pessimistic proof, or full execution proofs |
| Consortium setup | Supported | Supported |
Source: CDK Besu documentation.
How it works
A Polygon CDK Besu chain is a standard Besu network with a connection to Agglayer’s unified bridge built in. Alongside your QBFT validators, it runs a dedicated RPC node so the validators stay off the public network, plus a small set of open-source services that handle the connection.
- Bridge contracts on your chain. Agglayer’s bridge and Global Exit Root contracts are written into the chain’s genesis, so the connection exists from the first block.
- aggkit. It keeps your chain in sync with the shared bridge state, and packages your chain’s bridge activity into certificates for Agglayer.
- A proof, then settlement on Ethereum. Agglayer requests a pessimistic proof, generated on the Succinct Prover Network, that every connected chain’s bridge accounting balances. Once the proof is verified, the certificate settles on Ethereum.
- The claim. The bridge service picks up the settled transfer, and the asset is claimed on the destination chain.
CDK Besu is live and ready for production on Ethereum mainnet, with testnet and devnet setups for teams that want to evaluate first. The runbook covers every step, from the integration request to monitoring and key rotation.
What the proof guarantees, for your risk team
The question that usually stalls a cross-chain project in review is simple: what happens to our funds if the chain on the other side is compromised?
Agglayer’s answer is a cap enforced by math. The pessimistic proof treats every connected chain as if it could fail, and Agglayer won’t settle any update in which a chain withdraws more than was deposited into it. A compromised chain can lose its own deposits, but it can’t reach yours. There’s no committee of signers whose keys could approve a transfer that doesn’t balance.
Two things are worth knowing up front. First, your chain’s transaction data stays in your private infrastructure and isn’t posted to Ethereum. For a private ledger, that’s the intended design. Only the bridge activity needed for settlement reaches Agglayer. Second, the pessimistic proof covers bridge accounting, not every transaction inside your chain. Institutions that want every state transition proven can run a Polygon CDK chain on op-reth, which supports full zero-knowledge execution proofs.
Built for consortiums
Many bank networks are run by several institutions together, and none of them wants another member to be able to act alone. CDK Besu supports that directly, through two independent controls:
- Shared block production. Each member runs its own QBFT validator and keeps its own key. Adding or removing a member goes through a validator vote.
- Shared certificate approval. No certificate settles to Agglayer until M of N registered members have signed it, and each member checks the certificate against its own view of the chain before signing.
No single member can produce blocks or settle withdrawals on its own. The consortium chapter of the runbook covers key handling, signer setup and the operating agreements members need before launch.
Built in the open, like Besu itself
Many institutions chose Besu because it’s open source and governed in the open under the Linux Foundation, rather than controlled by a single vendor. We built the Agglayer connection the same way. The chain runs standard Besu, the runbook is public, and the components it deploys (aggkit, the bridge service and the bridge contracts) are open source.
That matters for a procurement review as much as for engineers. There’s no proprietary client to adopt, no fork to maintain, and no revenue share owed on the activity your network generates.
Already running Besu?
Many institutions already have a Besu network in production, with its own history, validators and users. Those networks can connect to Agglayer too, without starting over. The setup is different from launching a new CDK Besu chain, so talk to our team about what connecting your network involves.
Ready to launch a Polygon CDK Besu chain?
A Polygon CDK Besu chain doesn’t stand alone. The rest of the Polygon Open Money Stack is available alongside it for moving money in and out, including fiat on- and off-ramps, wallets and cross-chain routing. And if a use case calls for full zero-knowledge proofs of every transaction or much higher throughput from the start, Polygon CDK on op-reth is built for that and connects to the same Agglayer network.
To see the full deployment, read the CDK Besu documentation and the runbook, or talk to our institutional team about launching yours.
Introducing Polygon CDK Besu: Launch a Hyperledger Besu chain connected to other chains and their liquidity
Polygon Open Money Stack is now a U.S.-regulated payments platform with completion of Coinme acquisition
New to Polygon OMS: Automated stablecoin payout runs with rules your team sets
Polygon Open Money Stack now supports TRON
Meet Polygon at Money20/20 USA
Monerium, Frax and Capa connect euro payments to onchain FX markets on Polygon
Introducing crypto checkout in Polygon Open Money Stack
Polygon passes $3 trillion in stablecoin transfer volume
Polygon Chain now supports 11 million payments per second
