Security audits: what an audit report actually tells you

"Audited by" is one of the most common badges in crypto. It appears on websites, in pitch decks and in token launches, often as if it settled the question of whether something is safe. It doesn't — but a real audit report, read properly, tells you a great deal. The trick is knowing what to look for.

What an audit is

A security audit is a time-boxed review of specific code by an outside firm. Auditors read the code, test it, try to break it and write up what they find. For smart contracts, that usually means manual review plus automated tools; for wallets, it can include the apps, the cryptography, the servers they talk to and how all of them fit together.

The output is a report: what was reviewed, when, what was found, how severe each finding was, and whether the team fixed it.

Three phrases in that description matter more than the rest: specific code, time-boxed, and what was found.

Read the scope first

The scope says exactly what the auditors looked at — usually named repositories, contracts or components, often pinned to a particular commit.

That's where most misleading "audited" claims fall apart. A project might have audited one small contract and advertise the whole protocol as audited. A wallet might have had its smart contracts reviewed while the app that actually builds and signs your transactions was never looked at. If the thing you're trusting isn't in scope, the audit says nothing about it.

Ask: does the scope cover the parts that touch my funds?

Check the date and the version

An audit describes code as it was on the day it was reviewed. Everything shipped afterwards — new features, new chains, refactors — is outside it unless it was reviewed again.

That's normal; software keeps changing. But it means an audit from two years ago on a fast-moving project is a historical document. The useful questions are when it happened, which version it covered, and whether major changes since then have had their own review.

For smart contracts, there's an extra wrinkle: if a contract is upgradeable, the code running today may not be the code that was audited. Who controls upgrades matters as much as the audit itself.

Read the findings, not just the summary

Reports grade findings by severity — typically Critical, High, Medium, Low and Informational — and record whether each was fixed, acknowledged or left as is.

• Critical and High findings are the ones that could lose funds. Were there any, and were they fixed and re-checked?
• "Acknowledged" isn't "fixed". It means the team accepted the risk. Sometimes that's reasonable; read why.
• Zero findings isn't automatically good news. It can mean excellent code — or a narrow scope and a short engagement.
• Re-testing matters. A good report says the auditors verified the fixes, not just that the team said they'd made them.

What an audit can't tell you

Even a thorough audit has limits worth stating plainly:

• It's a sample of attention, not a proof. Auditors find many bugs; they don't find all of them. Audited protocols have been exploited.
• It covers code, not operations. How keys are stored, who can deploy, how the team handles an incident — usually out of scope.
• It doesn't cover economic design unless that was explicitly in scope. A contract can work exactly as written and still be exploitable through prices, incentives or other protocols.
• It doesn't cover what you install. An audit of source code says nothing about a fake app with the same name. Reproducible builds are what connect published code to the software you actually run.

Red flags in "audited" claims

• No link to the actual report, or a report hosted only by the project itself.
• An auditor you can't find, or whose site doesn't list the engagement.
• A scope that doesn't match what's being marketed.
• Unfixed high-severity findings described as "addressed".
• A single audit years ago, on a product that has changed completely since.

How SSP approaches it

SSP's code is open source, so anyone can read it — but open code and audited code aren't the same thing, and we treat them separately.

Halborn, an independent security firm, has audited SSP's ERC-4337 smart contracts, and the SSP Wallet extension, SSP Key app and SSP Relay together. Both reports are public on Halborn's site, with no critical or high findings, and the low and informational findings were addressed. Our 2025 audit recap lists the scope and dates of each engagement.

The same caveats apply to us as to anyone. Those audits cover the code as it was when it was reviewed; features and chains added since then aren't covered by them, so we say what kind of review newer code has had rather than stretching an old badge over it.

The honest summary

An audit is evidence, not a guarantee. It tells you that specific code, at a specific time, was reviewed by a specific firm, and what they found.

Read the scope, check the date and version, look at the severities and how they were resolved, and find the report on the auditor's own site. Do that, and "audited" stops being a badge and starts being information.