Paychannels on CDK Besu

Paychannels process payments offchain at a hub and settle them in periodic batches to a channel contract. CDK Besu runs a Hyperledger Besu chain with QBFT consensus, connected to Agglayer through pessimistic proofs. Deploy the channel contract on a CDK Besu chain and the hub settles on a ledger that your own validators operate, while funds still move to and from Ethereum and other Agglayer chains through the unified bridge. This page explains how the two fit together and how the combination scales. It assumes you have read the Paychannels overview and the CDK Besu page.

​

When to use this combination

Paychannels on CDK Besu fits an organization or consortium that wants high-frequency payments on infrastructure it controls:

• Payments at volume on a private ledger. The CDK Besu chain posts no transaction data to L1, and Paychannels keep individual payments off the chain entirely. The chain records only deposits, settlement roots, and withdrawals.
• Settlement on your own schedule and cost. The hub operator controls the chain the hub settles on, so settlement transactions do not compete with other traffic for block space.
• Shared control in a consortium. Members can each run a QBFT validator for the chain and a Paychannels verifier for the hub, so no single member produces blocks or settles a payment root alone.
• Connected liquidity. Stablecoins enter the chain through the Agglayer unified bridge, and merchants can bridge their earnings back out after they withdraw.

​

How the pieces fit

The channel contract is an ordinary contract on the CDK Besu chain. The Paychannels services talk to the chain through the Besu RPC node, and the Agglayer components connect the chain to L1 independently of them. A payer bridges stablecoins to the CDK Besu chain, deposits them into the channel contract, and pays through the facilitator. The hub posts an attested settlement root to the chain once per epoch. A merchant withdraws against a posted root and can bridge the funds to L1 or another Agglayer chain.

​

How it scales

Paychannels separate how often payments happen from how often anything reaches the chain. The chain’s block time and gas limit cap settlement, not payments.

​

Payment throughput

A payment is a signed voucher that the hub verifies and applies in memory. Nothing touches the chain per payment, so hub throughput does not depend on the chain the hub settles on. Hubs also do not coordinate with each other on the payment path, so capacity grows in a straight line as you add hubs. See Performance for the benchmarked figures, which measure the hub and are independent of the settlement chain.

​

Chain load

Only these operations send transactions to the CDK Besu chain: Settlement load grows with the number of hubs and the epoch interval. For example, 100 hubs that each close a 10-minute epoch post 100 settlement transactions every 10 minutes, about one every six seconds, whatever their combined payment volume. A CDK Besu chain with the runbook’s one-second block period has ample room for that load. Because the operator controls the chain, it can choose a short epoch interval. Shorter epochs shrink the window in which new earnings cannot yet be withdrawn. See Limits to plan around.

​

Agglayer load

Payments and settlement roots do not create bridge events. The certificates that aggkit submits to Agglayer cover only the chain’s bridge exits and claims, so payment volume adds nothing to certificate size or proving work. Agglayer load grows only with how often funds move on or off the chain.

​

Security model

Each layer secures a different property. Plan for all three.

• Paychannels verifiers secure the payment ledger. The channel contract accepts a settlement root only with signatures from a threshold of registered verifiers, each of which re-checks every payment in the epoch. The hub operator never holds the money. See Trust model.
• QBFT validators secure the chain. The channel contract’s deposits, roots, and withdrawals are as final as the CDK Besu chain itself. QBFT tolerates f faulty validators with at least 3f + 1 validators.
• The pessimistic proof secures the bridge. It proves the chain cannot withdraw more from the unified bridge than was deposited into it. It does not prove the chain’s internal state transitions, so it does not verify the channel contract’s state. That trust rests on the chain’s validators.

In a consortium, split both sets of signers across members: each member runs its own QBFT validator and its own Paychannels verifier, and you set the verifier threshold so that no single member can settle a root alone. See Consortium configuration.

​

Privacy

Paychannels keep individual payments, counterparties, and amounts off the chain. CDK Besu keeps the chain’s own transactions off L1. Together:

• L1 and Agglayer see only bridge deposits and exits for the chain.
• The CDK Besu chain records deposits, settlement roots, and withdrawals. Only parties with access to the chain’s RPC can read them.
• The hub operator and its verifiers see individual payments and balances.

See Privacy for what each Paychannels party can read and how account data in settlement roots is blinded.

​

Before you deploy

These requirements come from how the Paychannels services interact with a Besu chain. Settle them before you generate the genesis and deploy the channel contract.

• Match the EVM version. Your genesis must activate every fork the channel contract is compiled for. The runbook’s sample genesis activates forks up to Shanghai (shanghaiTime), and a contract compiled for a later fork can fail at runtime on that chain. Confirm the EVM version of the contracts in your operator release before launch, since adding a fork later requires a coordinated upgrade of every node.
• Keep London active. The hub engine, facilitator, and claim runner price their transactions with EIP-1559 fee estimates. The runbook’s genesis activates London at block 0; keep it.
• Choose a settlement asset. Channel deposits accept any ERC-20 token. The exact scheme also needs EIP-3009 transferWithAuthorization, which tokens the unified bridge wraps by default do not implement. With a bridged stablecoin, payers pay through channels only.
• Lower the confirmation depth. The hub engine, verifiers, and facilitator treat a block as final only after --confirmation-depth blocks, 15 by default. QBFT finalizes each block when it is produced, so you can lower this value and let deposits count sooner. Use the same value on every service.
• Allowlist Paychannels addresses. If you enable Besu account permissioning, add every address that sends transactions to the channel contract: the operator key, the facilitator submitter key, the claim runner key, and any payer or funder that deposits directly. Apply the same allowlist on every validator and RPC node.
• Connect through the RPC node. Point every Paychannels service’s --rpc-url at the Besu RPC node, not a validator, and add the services’ hostnames to the node’s --host-allowlist.
• Decide on gas. With the runbook’s zero-gas configuration (zeroBaseFee and --min-gas-price=0), settlement and withdrawal transactions cost no gas. If you enable a fee market, fund the operator, facilitator submitter, and claim runner keys with the chain’s gas token.

​

Deploy

​

Related