What a Wallet Audit Actually Covers

Wallet and platform marketing cites audits. Reading one properly takes fifteen minutes and changes what the citation means.

The five questions

1. Which firm, and does it publish its own reports? Reputable security firms publish. A report existing only on the vendor’s site is unverified.

2. What was the scope? An audit covers specific components. A report on a signing library says nothing about the interface that constructs transactions, which is where several real-world failures have occurred.

3. Which version? Reports name a commit or a release. Software ships continuously. An audit of a version from two years ago covers code that may no longer exist.

4. What were the findings, and were they fixed? Real audits find issues. A report with no findings is either a trivial scope or a document that is not an audit. Findings marked acknowledged rather than resolved are issues that still exist.

5. Was the build verified? Whether the audited source corresponds to the binary users install. Without reproducible builds this link is unestablished regardless of the audit.

What an audit does not establish

That the software is safe. It establishes that a firm examined specific code at a specific time and reported what it found.

That the current version is covered.

That the threat model is right. An audit checks implementation against intent. If the intent is flawed, a correct implementation of it is still a problem.

Anything about the interface. Most user losses come from approving something that was displayed misleadingly, which is a design question rather than a cryptographic one.

The finding category worth reading

Centralisation and trust assumptions. Audits routinely note that an operator can upgrade a contract, pause transfers or control a key.

Those appear as findings, are frequently marked acknowledged, and are the vendor telling you what it can do, inside a document cited as evidence of safety.

The practical hierarchy

For a wallet: standard recovery first, transaction simulation second, audit history third.

For a platform: regulatory authorisation first, asset segregation second, published reserve attestation third.

Audits appear on both lists and at neither top, which is different from how they are presented.

The version check

For anything upgradeable, compare the current implementation against the audited commit.

That single check closes the most common gap between what an audit covered and what is running, and almost nobody performs it. Venues publishing their audit and attestation details alongside their registration, such as venues supporting external addresses, make the equivalent check possible on the platform side.