Polygon introduced CDK Besu on October 19, 2026. Its current documentation says the described Besu configuration does not serve the safe and finalized block tags, despite QBFT finalizing blocks when produced. If a payment screen encounters that RPC error, first diagnose the unsupported query; the error alone does not establish that the transaction failed or disappeared.
The launch adds a configuration with its own assumptions
The launch announcement presents a private Besu chain connected to Agglayer. A team already familiar with another CDK configuration should still review the new one’s interfaces. A shared product family does not make every block-status request interchangeable across clients and consensus systems.
What the documented RPC error actually describes
The CDK Besu overview identifies error -39001 for the safe and finalized tags and tells operators to configure aggkit to track latest blocks. This is guidance for the documented deployment. It is not permission to rename every latest block finalized in an unrelated network or to remove a receiving service’s confirmation policy.
Keep the failed query and the transaction reference separately. A dashboard can fail to obtain a requested block view while the question of what happened to a particular transfer still needs investigation. Save the chain identity, method, requested tag, endpoint and observation time. Those details help the operator determine whether the screen requested something that this setup supports.
| Observed problem | First record to inspect | Question still open |
|---|---|---|
| A tagged RPC query returns an error | The method, tag and chain configuration | What happened to the identified transaction? |
| The local transaction has an observed result | The result on the intended chain | Has any required bridge process completed? |
| A bridge movement has progressed | The matching settlement and destination records | Did the intended receiving service credit it? |
| The interface still shows pending | Which underlying record drives that label? | Is the delay in the query, bridge or recipient’s own processing? |
Local block finality and bridge completion answer different questions
The public runbook distinguishes local block production from certificate processing and settlement on L1. Its security description also limits pessimistic proofs to bridge accounting; they do not prove every internal state transition of the private chain. Read the evidence for the step you are checking instead of treating one technical success as the outcome of the entire route.
For an illustrative support case, imagine that a local transfer is visible but a screen’s finalized-tag query returns an error. The operator resolves the query compatibility issue and then checks whether a separate cross-chain movement was even requested. That second check matters: fixing a display query does not create a bridge operation, and a local transfer should not be presented as a destination-chain receipt without matching evidence.
A useful support message preserves the failed question
- Confirm the intended chain with the application’s official network information.
- Keep the transaction reference and the exact RPC error without including private keys or authentication secrets.
- Record which method and block tag produced the error, along with the observation time.
- Ask the operator which supported query establishes the relevant local result.
- If the operation crosses chains, obtain the matching bridge and destination status before treating the payment as complete.
Do not send a replacement payment merely because the interface could not read a block tag. First resolve what happened to the original instruction. If you are the integration operator, follow the current runbook for your actual components and verify the application’s status mapping. This article did not run a node, query a live private chain or reproduce the error against a funded account.
Check the receiving product before a separate exchange
A chain’s Agglayer connection does not establish deposit support at every service. For an exchange, check supported coins and networks, read how the order works, and use the simple-swap form for that order’s instructions. The CDK Besu announcement does not identify a supported private-chain deposit route at KOT.CASH. The intended asset, network and recipient remain part of the actual transaction review.
FAQ
What does the Hyperledger Besu documentation say about these block tags?
The CDK Besu overview describes unsupported safe and finalized tags for its deployment. Check that documented scope before applying the behavior to a different Besu setup.
Where is the Polygon CDK Besu runbook on GitHub?
The article links to the public 0xPolygon/cdk-besu repository. Review its current scope and component guidance rather than assuming every CDK configuration behaves alike.
What should I check about my Hyperledger Besu network before a transfer?
Confirm the intended chain and the receiving product’s actual instructions. A supported bridge connection alone does not establish deposit support at that service.