Swap security

How to read an audit claim before using an aggregator

Read the audit’s scope, version, findings and deployment relevance before treating an aggregator’s audit badge as security evidence.

An audit claim is useful only when you can connect the actual report to the contracts and version you will use. Start with the report itself, preferably hosted by the auditor or linked from independently verified official sources.

Match the reviewed system

Find the repository, commit or release, contract files, review dates and exclusions. Determine whether the report covers the router, allowance component, settlement system, bridge or only a supporting library.

As a historical example of report structure, OpenZeppelin’s 2022 account-abstraction audit specifies a commit, excluded files, assumptions and subsequent fix references. That report is not evidence that any aggregator is audited; it illustrates the details a meaningful scope statement contains.

Read findings and resolution status

Do not stop at the number of critical issues. Examine unresolved high-impact findings, accepted risks, centralization assumptions and limitations. “Acknowledged” can mean the team accepted a risk rather than removed it. A resolved label should identify what changed and whether that change received follow-up review.

Compare the audited code with the deployed version using official deployment records. A later upgrade or new contract can fall outside an earlier report.

Ask what the audit cannot establish

  • Did it review the front end, operational keys and deployment process?
  • Did it assess external token behavior and every liquidity integration?
  • Does it assume administrators act honestly?
  • Are economic or cross-chain assumptions outside scope?

These are review questions, not claims that every report excludes those areas. The report should tell you where its boundary lies.

Turn the evidence into a bounded conclusion

A defensible conclusion is that a named reviewer examined a specified version under stated assumptions and that identified issues have documented outcomes. “Guaranteed safe” goes beyond that evidence.

Keep reviewing the transaction you actually sign. An audited router does not validate an unrelated approval spender supplied by a compromised website, and a genuine audit does not make an unlimited permission risk-free.

Sources & verification (3)

Source-check date is recorded in the article details. URLs are provided for manual verification. Use Copy to keep this page open.

  1. EIP-4337 – Ethereum Account Abstraction Audit

    Historical example of explicit commit, scope, exclusions, assumptions and resolution updates; not an audit claim for an aggregator.

    https://www.openzeppelin.com/news/eth-foundation-account-abstraction-audit
  2. Verifying smart contracts | ethereum.org

    Source-code correspondence differs from formal verification and security review.

    https://ethereum.org/developers/docs/smart-contracts/verifying/
  3. Contracts | 0x Docs

    Allowance targets differ from execution entry points; 0x warns against allowances to Settler.

    https://docs.0x.org/docs/core-concepts/contracts

Continue reading

Verified source code is not an audit or safety guarantee Why a router upgrade can change the risk of an old approval