> ## Documentation Index > Fetch the complete documentation index at: https://docs.polygon.technology/llms.txt > Use this file to discover all available pages before exploring further. # Paychannels on CDK Besu > Run a Paychannels hub that settles on a CDK Besu chain connected to Agglayer: how the pieces fit, how throughput scales, what each layer secures, and what to configure before you deploy. [Paychannels](https://docs.polygon.technology/pos/paychannels/overview.md) process payments offchain at a hub and settle them in periodic batches to a channel contract. [CDK Besu](https://docs.polygon.technology/chain-development/cdk/cdk-besu/overview.md) 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](https://docs.polygon.technology/pos/paychannels/overview.md) and the [CDK Besu](https://docs.polygon.technology/chain-development/cdk/cdk-besu/overview.md) page. > [!NOTE] > > Running a Paychannels hub is in early access. [Contact Polygon](https://polygon.technology/get-access) for the operator release, which includes the hub binaries, contracts, and deploy scripts. ## 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. | Layer | Components | Role | | - | - | - | | Payments | Hub engine, facilitator | Verify and apply each signed payment offchain, keep the ledger, and close epochs | | Payment settlement | Verifiers, channel contract | Re-check every payment in an epoch, co-sign the settlement root, and hold deposits | | Chain | Besu validators (QBFT), Besu RPC node | Finalize the deposits, settlement roots, and withdrawals that reach the chain | | Interoperability | aggkit, bridge service, Agglayer node | Bridge assets in and out and settle the chain's bridge activity on L1 with pessimistic proofs | ```mermaid theme={null} flowchart LR Payer((Payer)) Merchant((Merchant)) L1[L1] subgraph PAY[Paychannels] fac[Facilitator] hub[Hub engine] ver[Verifiers] end subgraph BESU[CDK Besu chain] rpc[Besu RPC node] val[Besu validators, QBFT] hubc[Channel contract] bridgec[Bridge contract] end subgraph AGG[Agglayer components] aggkit[aggkit] agglayer[Agglayer node] end Payer -->|Signed payments| fac Merchant -->|Settle payments| fac fac -->|Payment stream| hub hub -->|Epoch evidence| ver ver -->|Root signatures| hub hub -->|One attested root per epoch| rpc rpc --> val val --> hubc val --> bridgec aggkit -->|Certificates for bridge activity| agglayer agglayer -->|Settle with pessimistic proof| L1 ``` 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](https://docs.polygon.technology/pos/paychannels/overview.md#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: | Operation | Frequency | | - | - | | Settlement root | One transaction per hub per epoch, carrying the root and the verifier signatures, whether the epoch covers one payment or 100 million | | Deposit | Once per top-up of an account's deposit | | Withdrawal | Once per withdrawal request and redemption | | Direct (`exact`) payment | One transfer per payment, only for payers without a channel | 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](https://docs.polygon.technology/pos/paychannels/trust-model.md#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](https://docs.polygon.technology/pos/paychannels/trust-model.md). * **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](https://docs.polygon.technology/chain-development/cdk/cdk-besu/overview.md#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](https://docs.polygon.technology/pos/paychannels/privacy.md) 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 **1. Deploy the CDK Besu chain** Follow the [`cdk-besu` runbook](https://github.com/0xPolygon/cdk-besu) through [Verification and operations](https://github.com/0xPolygon/cdk-besu/blob/main/06-verification-and-operations.md), applying the genesis and permissioning requirements above. Confirm the chain settles certificates on Agglayer before you continue. **2. Make the settlement asset available** Bridge the stablecoin you will settle in to the chain through the unified bridge, or deploy it natively, and record its address on the chain. **3. Deploy and run the hub** Follow [Run a hub](https://docs.polygon.technology/pos/paychannels/run-a-hub.md) with `RPC_URL` set to the Besu RPC node and `CHAIN_ID` set to the CDK Besu chain ID. Pass your chosen `--confirmation-depth` to the engine, every verifier, and the facilitator. **4. Verify settlement** Run the terminal steps in [Try a demo](https://docs.polygon.technology/pos/paychannels/try-a-demo.md#from-your-terminal) against your facilitator. After one epoch interval, confirm that `EpochRootPosted` and `RootAttested` events appear on the CDK Besu chain. ## Related > **[Paychannels overview](https://docs.polygon.technology/pos/paychannels/overview.md)** > > How Paychannels work, use cases, and benchmark results. > **[Run a hub](https://docs.polygon.technology/pos/paychannels/run-a-hub.md)** > > Deploy the channel contract, verifiers, hub engine, and facilitator. > **[CDK Besu](https://docs.polygon.technology/chain-development/cdk/cdk-besu/overview.md)** > > What the CDK Besu runbook deploys and how it differs from CDK op-reth. > **[Pessimistic proof](https://docs.polygon.technology/interoperability/agglayer/core-concepts/pessimistic-proof/architecture.md)** > > How Agglayer caps what a connected chain can withdraw from the bridge.