“Audited” is one of the most reassuring words in crypto marketing, and one of the least informative. A bridge can be audited and still lose hundreds of millions of dollars. The audit may have covered an older version of the code, left out the components that failed, or flagged the exact weakness that was later exploited, with the team choosing not to fix it.
Bridges deserve particular care. They hold large pools of locked assets, connect systems with different security rules and rely on off-chain components that a code audit may never examine. Several of crypto’s largest losses, including Ronin, Wormhole, Nomad and Poly Network, came from bridges.
This guide explains how to read a bridge audit report properly. It covers what to check first, which findings matter most for bridges and what an audit cannot tell you. It is written for founders, product leads and integrators as well as engineers.
What does a smart contract audit report contain?
Most audit reports follow a similar structure. They begin with a summary and a scope section listing the repository, commit hash and files reviewed. A methodology section describes how the auditors worked, for example through manual review, automated tools, fuzzing or formal verification.
The core of the report is the list of findings. Each finding usually includes a severity rating, a description, the affected code, a recommendation and a status showing how the team responded. Many reports end with a fix review, where auditors confirm whether the changes resolved each issue.
Reading a report well means looking at each of these parts, not just the summary page.
Step 1: Confirm what was actually audited
Start with the scope. It decides whether the report applies to the bridge you are evaluating at all.
Check the commit hash. The report should name the exact version of the code that was reviewed. Compare it with the deployed contracts, which can usually be verified on a block explorer. If the deployed code differs, the changes since the audit have not been reviewed.
Nomad’s loss in August 2022 shows why this matters. A routine upgrade initialised a trusted value incorrectly, which let the contract accept unproven messages. Around $190 million left the bridge. The problem came from how the code was deployed and configured after review, not from code that auditors had signed off in that form.
Check what was left out. Bridges have many moving parts: on-chain contracts on each chain, relayers, validators or guardians, oracles, frontends and deployment scripts. Code audits often cover only the contracts on one or two chains. If the off-chain signing system or the verification logic on a second chain was out of scope, the report says nothing about it.
Check the date. An audit from two years ago reviewed a different codebase, written against different chain assumptions.
Step 2: Read the findings that matter most for bridges
Severity ratings help, but not every high-severity finding carries the same weight. For bridges, certain categories deserve the closest reading.
Message and signature verification
A bridge exists to decide which cross-chain messages are genuine. Any finding that touches signature checks, proof verification or message validation goes straight to the heart of its security.
Wormhole lost around $320 million in February 2022 because its Solana contract relied on a deprecated function that failed to confirm a system account was genuine. An attacker used that gap to forge a valid-looking approval. Findings involving signature verification, account validation or proof checking should never be dismissed as minor.
Access control and privileged roles
Bridges usually have powerful roles: admins who can upgrade contracts, operators who manage validator sets and guardians who can pause transfers. Findings about who holds these powers, and whether they can be gained unexpectedly, are critical.
In August 2021, Poly Network lost around $611 million when an attacker crafted a cross-chain message that changed the bridge’s privileged keeper role. Most of the funds were later returned, but the lesson stands. Cross-chain messages should never be able to modify critical access control.
Initialisation and upgrade logic
Upgradeable bridges add risk at every deployment. Findings about initialiser functions, storage layout in proxies or missing checks during upgrades deserve close attention, because the bridge’s security depends on these steps going right every time.
Replay and nonce handling
A message valid on one chain should not be accepted twice, or on a different chain. Look for findings about nonces, chain identifiers and message hashing. Replay weaknesses can let an attacker withdraw the same deposit more than once.
Supply accounting
For lock-and-mint bridges, the wrapped tokens minted on one chain must never exceed the assets locked on the other. Findings that suggest supply could drift, through rounding, fee-on-transfer tokens or failed refunds, point to a core invariant being at risk.
Centralisation and key management
Many reports include findings or notes about centralisation, often rated low or informational. For bridges, these deserve far more weight than the label suggests.
Ronin lost about $625 million in 2022 after attackers controlled five of its nine validator keys. Harmony’s Horizon bridge lost about $100 million the same year with a two-of-five multisig. Neither loss came from a classic code bug. If a report notes that a small group of keys controls funds or upgrades, treat it as a serious finding regardless of its label.
Finality and reorganisation handling
Bridges must wait until a source-chain transaction is final before acting on it. Findings about confirmation thresholds, reorganisation handling or finality assumptions matter, especially for chains where finality works differently.
External dependencies
Bridges often rely on oracles, token contracts and messaging libraries. Look for findings about unusual token behaviour, such as rebasing or fee-on-transfer tokens, and about trust placed in external contracts.
Step 3: Read the status of each finding
A finding’s status often matters more than its severity. Common statuses include:
Fixed or resolved. The team changed the code, and ideally the auditor confirmed the fix.
Partially fixed. Some of the issue remains. Read the details carefully.
Acknowledged. The team accepts the issue but chose not to change the code. This is the status to read most carefully.
Disputed. The team disagrees with the auditor. Read both sides and decide for yourself.
An acknowledged high-severity finding on a bridge is a serious warning. Sometimes there is a good reason, such as a risk handled elsewhere in the system. That reason should be documented and convincing.
Step 4: Judge the quality of the audit itself
Not all audits are equally thorough. A few signals help separate deep reviews from quick ones.
Time and size. A large bridge reviewed in a few days by one auditor received far less scrutiny than one reviewed over several weeks by a team. Many reports state the review period and team size.
Methods used. Fuzzing, invariant testing and formal verification of key properties, such as supply accounting, signal a more rigorous process than manual review alone.
A fix review. Reports that confirm each fix are more useful than those that list findings and stop.
Multiple independent audits. For bridges holding significant value, several audits from different firms, or a competitive audit contest, give broader coverage. Different teams tend to catch different classes of bugs.
Note that a short list of findings does not prove the code is safe. It may reflect a narrow scope or a brief review.
What can an audit not tell you?
Even an excellent audit has limits. It usually does not cover:
How validator or signer keys are generated, stored and protected.
Whether the team monitors the bridge and can respond quickly to an
incident.
Economic risks such as liquidity shortfalls or incentive problems.
Code changes made after the audit.
Social engineering attacks against team members.
Operational security caused several of the largest bridge losses. An audit report should be one input into a wider assessment that also covers governance, key management, monitoring and incident response.
Questions to ask a bridge team after reading the report
Use the report to ask the team:
Does the deployed code match the audited commit, and if not, what
changed?
Which components were out of scope, and how were they reviewed?
Why were acknowledged findings left unfixed?
Who holds upgrade, pause and validator keys, and how are they
protected?
Is there an active bug bounty, and how large is it?
How quickly can the team pause the bridge if something goes wrong?
Getting help evaluating or building secure cross-chain features
Reading audits well takes practice, and many teams that integrate bridges into their own products lack in-house security specialists. Some Hire Dedicated dApp Developers with security experience to review audits and integration code. Others work with a Decentralized Application Development Company that handles bridge integration and audit preparation as part of a wider build.
When comparing DApp Development Services, ask how a provider scopes audits, chooses audit firms and handles findings marked as acknowledged. An experienced DApps Development company should be able to walk through past audit reports and explain the decisions behind each one.
Conclusion
A bridge audit report is only useful when it is read in full. Check that the scope matches the deployed code and covers the critical components. Give extra weight to findings about message verification, access control, upgrades, replay, supply accounting and centralised keys. Read the status of every finding, especially those acknowledged but unfixed, and remember that operational risks often sit outside the audit entirely.
Codezeros offers Decentralized Application Development Services covering bridges, DeFi and enterprise projects, and its DApp development page explains how its team approaches audit preparation within Web3 dApp Development. For anyone relying on a bridge, the practical habit is simple: never stop at the word “audited,” and always read what the auditors actually found.
FAQs
What should I check first in a bridge audit report?
Start with the scope. Confirm the audited commit matches the deployed contracts, check which components were included and note the audit date. Code changed or excluded from the audit has not been reviewed.
Which audit findings are most serious for bridges?
Findings about message or signature verification, access control, upgrade logic, replay protection, supply accounting and centralised key control deserve the most attention. Past bridge losses at Wormhole, Poly Network, Nomad and Ronin involved these areas.
What does “acknowledged” mean in an audit report?
It means the team accepts the auditor’s finding but chose not to change the code. The team should explain why. An acknowledged high-severity finding on a bridge deserves careful questioning before you trust the bridge with funds.