Reading audit evidence for your planned cBridge route

An audit supports a cBridge route only to the extent that its reviewed contracts, version and scope match the route you plan to use.

Match the audit to the route’s bridge contracts

Start by identifying the route’s source and destination networks, token and bridge model; then find the audit report for the contracts that handle that transfer. The cBridge Audit Reports index separates liquidity-bridge and canonical-bridge reports, so an audit for one model does not automatically apply to the other. A token’s route can depend on which model handles it, not just on the networks involved.

Before proceeding, confirm that the token and network pair are currently supported; cBridge supported chains is relevant to that eligibility question. Support alone does not tell you which contracts implement the route or whether those contracts match an audited version. Use the official report links to read the report itself and identify the component, version and stated review scope.

A report’s scope is the boundary of what auditors examined. It may name particular contracts or source files and describe the assumptions or exclusions for the review. If it covers a liquidity-bridge component, for example, it does not establish that a canonical-bridge contract used by another route received the same review. Match the report’s named components to the route’s contracts before treating it as relevant evidence.

Confirm the reviewed code matches the live deployment

A report establishes that auditors reviewed the code and version it names; it does not by itself establish that the live contract on your chosen network runs that version. Compare the report’s repository or commit details with the deployed contract information in the official contract-address records. If you cannot confirm the match, record the audit as evidence about that code, with the deployment match unresolved.

Then read the findings and remediation notes. A listed issue may be fixed, accepted, or still open; the presence of a report alone does not show which outcome applies. Look for a clear account of the resolution and whether the change was included in the version you are comparing. A fix made after the review may need separate evidence that the changed code was reviewed.

Keep the audit’s limits in view

A contract audit does not automatically cover every part of a cross-chain transfer. Ethereum.org’s “Smart contract security” documentation explains that audits provide an additional code review but cannot identify every bug. A route may also rely on other contracts, validators, frontend integrity, administrative operations and the underlying chains. A review limited to bridge contracts does not establish the security of those other components or how they will operate during your transfer.

That distinction matters even when a report names a familiar component such as the State Guardian Network: check whether the report actually includes the relevant validator software or operations. The cBridge Audit Reports index lists validator-node audits as in progress, so its smart-contract reports should not be read as evidence that validator nodes were audited. Network congestion or a chain failure also sits outside what a contract-code review can certify.

Use the available evidence to make a bounded statement: which contracts and version were reviewed, whether they match the intended route, what findings were addressed, and which parts remain outside scope or unverified. An audit is not a guarantee, a measure of your transfer’s loss probability or a promise of reimbursement. Before sending, assemble those points for your exact route; the next action should establish whether the live contracts match the reviewed version and whether any unresolved scope gap changes your decision to proceed.