Explainer · 7 min read
The smart contract auditor landscape for teams shipping on Arc
No firm has a publicly sourced Arc-specific audit as of 2 Sep 2026. What an audit actually covers, what to ask a firm for, and why it isn't a guarantee.
Circle's own developer documentation for Arc does not publish a vendor list for smart-contract auditors, unlike its curated lists for RPC providers, indexers, oracles, and account abstraction. Built on Arc found no publicly disclosed engagement naming a specific audit firm and a specific Arc project as of 2 September 2026. This guide covers what an audit is and isn't, what a team building on Arc should ask a firm for, and why "audited" is a claim to verify, not a safety guarantee to take on faith.
The current state of the record
This is a landscape guide with an honest gap in it: unlike RPC, indexing, oracles, and account abstraction, Arc's audit ecosystem has no Circle-published vendor list and no public audit report Built on Arc could source naming a firm and an Arc project together. That's not the same as saying no audits are happening — teams commonly commission audits privately and publish (or don't) on their own timeline, often close to launch rather than during testnet. With mainnet at 16 September 2026, it wouldn't be surprising if reports for early Arc-native projects surface around or after that date. As of this writing, none had.
This guide does not name a firm as having audited an Arc project, and will not, absent a sourced report. It also does not recommend or rank firms — Built on Arc doesn't rank providers in any category.
What an audit actually is
A smart-contract audit is a scoped, time-boxed manual and automated review of a specific version of a specific codebase, performed by a security firm, that produces a report listing findings by severity (critical, high, medium, low, informational) along with the auditor's assessment of whether each was fixed, acknowledged, or left open. It is bounded by what was in scope: a report covering a token contract does not cover a governance module added later, a proxy upgrade deployed after the audit's snapshot commit, or an off-chain component like a keeper bot or oracle integration unless that was explicitly included.
What an audit is not
An audit is not a guarantee of safety, and no reputable firm's own terms claim otherwise — most reports carry an explicit disclaimer that the review doesn't eliminate risk and isn't a certification. It is not evidence a contract will never be exploited: audited protocols have been hacked, sometimes through the exact bug class the audit reviewed but a specific instance it missed, sometimes through something entirely out of scope (admin key compromise, oracle manipulation, a dependency added later). It is not proof the deployed contract matches the audited code — that requires checking the audited commit hash against the actual on-chain bytecode, a step many skip. And a single audit is not the same as an audit *and* a public bug bounty, which most serious protocols run in parallel rather than as a substitute.
What to actually ask a project for
Before treating a project's "audited" badge as meaningful: ask for the report itself, not a summary graphic. Check the date and the commit hash or contract address it covers against what's actually deployed. Check which findings were marked resolved versus acknowledged-but-unfixed — an acknowledged high-severity finding left open is a materially different situation from a clean report. Check whether the audit covered the full system in production (including any admin functions, upgrade paths, and third-party dependencies like oracles or bridges) or just a core module. And check whether the firm named is one whose reputation you can independently verify — a report from an unknown or unverifiable entity carries little more weight than no report at all.
Why this matters more, not less, before Arc mainnet
Pre-mainnet is exactly when audit claims are hardest to verify and most likely to appear anyway, because teams racing toward a launch date have every incentive to claim security review status before it's fully substantiated. Built on Arc's broader guidance on evaluating a project before using it — checking claims against primary sources rather than a project's own marketing — applies with particular force here: /guides/how-to-read-an-arc-project-entry.
Where audit actually shows up on Built on Arc
No audit firm has a sourced Arc-specific engagement as of 2 Sep 2026 — check back after mainnet. There is no browsable directory of audit firms here, because there is nothing yet to list: audit isn't a category a team sources like RPC or indexing, it's an on-chain check shown on a project's own page, and only for the Deploys and Issues roles. See how on-chain checks work for what Built on Arc records there, and for which roles it applies to.
Sources: - Arc developer documentation - Arc compliance vendors reference - Arc account abstraction providers
*Built on Arc is an independent directory. Arc is a Circle product; we are not affiliated with, endorsed by, or operated by Circle.*
Questions
Has any Arc project been audited as of 2 Sep 2026?
Built on Arc found no publicly sourced report naming both a specific firm and a specific Arc project as of this date. That may change quickly around mainnet; this guide reflects the record as it stood on 2 Sep 2026.
Does Circle audit projects that build on Arc?
Not as far as Built on Arc could verify — Circle's role documented on docs.arc.io is publishing infrastructure and vendor lists for RPC, indexing, oracles, AA, and compliance; auditing third-party application code is a different function and no evidence of Circle performing it was found.
Is an audit required to launch on Arc?
No. Arc's protocol layer does not require or check for an audit before a contract can be deployed. Under Built on Arc's model, an audit is one of the on-chain checks shown on a project's own page for Deploys and Issues roles specifically — never a directory-wide signal — so its absence here reflects the market, not this site's design.
What's the difference between an audit and a bug bounty?
An audit is a bounded, time-limited review by a paid firm before or around launch; a bug bounty is an ongoing, open invitation (usually with a payout scale by severity) for anyone to find and responsibly disclose issues after launch. Serious protocols tend to run both, not one instead of the other.
Can I trust a project's claim that it's "currently being audited"?
Treat it as a status claim to verify, not a completed fact — "currently being audited" has no defined end date and no report to check until the process finishes. It says something about intent, not outcome.
Where do I check if an audit firm itself is legitimate?
Look for a track record of previously published, checkable reports for well-known protocols outside the Arc ecosystem, a real public team, and a history that predates the project you're evaluating. This guide won't name specific firms as vetted or not — that's outside what Built on Arc can verify at scale.