Shiba Classic LogoShiba Classic

It's audited.

Legendary Klack
Legendary Klack19 Oct 2026

What an audit really covers, what it leaves out, and how to read one for any token.

Safe, they said · 2/10

Created by:

Legendary Klack

Tags:

Audit
Security
Multisig

"It's audited" ends more discussions than any other sentence in crypto.

It is true surprisingly often. And it tells you much less than it sounds like.

This is part two of our series "Safe, they said." Ten sentences that projects use to calm you down, one a week. Here is the second one, taken apart.

What an audit is, in one paragraph

A project pays a security firm to read its code. The firm gets a fixed version of that code and a fixed amount of time. It looks for mistakes, writes them down with a severity, and the project answers each one. The result is a report with a date on it.

So an audit is a statement about one version of some code, at one point in time, by people who can miss things. A good report says so itself, usually near the end.

Limit one: the scope

The report covers what the firm was given. Usually that is the contracts. It is usually not the website, not the servers, not the settings the contracts are deployed with, and not the keys that control them.

"Audited" without the word "what" is half a sentence.

Limit two: the date

Code changes. A contract that can be upgraded can be replaced the day after the report. Then the report describes something that no longer runs.

The question is not "was it audited?" but "is the thing that runs today the thing that was read?"

Limit three: found is not fixed

A report lists findings, and next to each one a status. "Resolved" or "fixed" means the mistake is gone. "Acknowledged" means the project has read it and left it as it is. A project with either status can say "audited".

Limit four: the keys

This is the one that costs the most money.

On 1 April 2026 a large trading protocol on Solana lost about $285 million, by the count of the security firm Cyfrin. Cyfrin and the protocol itself both say that no flaw in the contracts was used.

The protocol's admin rights sat with a multisig in which two of five signers were enough. According to the protocol's own preliminary findings, attackers spent about six months building trust with contributors, in person, at conferences. They likely compromised devices and obtained signatures on transactions whose real content the signers could not see. Those were held back and executed later. The drain took about twelve minutes.

No reading of the code could have found that. The code did exactly what valid signatures told it to do.

An audit checks whether the lock works. It does not check who holds the keys, or how they are protected.

How to check it for any token

You do not need to trust a website for this, including ours.

  1. Find the report on the auditor's own site, not only on the project's.
  2. Compare the address or code version in the report with the one in use today.
  3. Read the status of every finding. Count "resolved" and "acknowledged" separately.
  4. Read the scope. Look for what is not in it: admin keys, upgrades, the bridge, the website.
  5. Ask whether the contract can still be changed, and by whom. If it can, the report has an expiry date that nobody printed on it.

Where SHIBC stands

The SHIBC token contract was audited by Hashlock in December 2024. The report is public on Hashlock's site. The rating is "Secure", with one low-severity finding, one gas note and four quality notes.

All six are marked "Acknowledged", not "Resolved". They are minor. The contract's ownership is renounced, so nobody can change its code any more. What the auditor read in 2024 is what runs today.

Hashlock keeps a higher rating for projects with a bug bounty or on-chain monitoring. Both are planned: a disclosure programme with a published scope, and monitoring.

The audit covers the token contract. What is being built around it has its own gates before mainnet. For the bridge they are written down in our whitepaper, section 7.6. The details of the audit are in section 8.7.

What we take from it

An audit is evidence, not a guarantee. It answers "is this code what it claims to be?" It does not answer "who can change it, and who can move the funds?"

Our view of how a token should be run: say what was read, by whom and when. Say what was left as it is. And treat the keys as the larger question, because they are.

Next week, part three: "We have a multisig."