Fortifying Our Walls: V1 Security Hardened with Certik Audit

By DeHub Team — 2021-07-04

Following the v1 smart contract vulnerability, we commissioned a full audit with Certik in Q3 2021 and addressed what it found.

Audits get used as marketing in this industry, so it is worth writing this one down accurately: what we had it done for, what it covered, and what it did not prevent.

Why after, not before

The uncomfortable answer is that v1 shipped without one. The community had voted on the token's fundamentals, the launch was moving, and a full audit is weeks of calendar time and a meaningful cost for a project that had not yet listed.

That was the wrong trade and the vulnerability proved it. Every contract we have deployed since has been audited before it went live, not after. It is a policy that exists because of this quarter.

What the audit actually is

An audit is a structured, adversarial read of the code by people who are paid to find things and have no stake in the outcome. A good one produces a list of findings by severity, a set of recommended changes, and a record of which ones you actually made.

That last part is where audits get misrepresented. "Audited by Certik" is not a finding — a report with unresolved criticals is still an audit. The useful claim is that findings were resolved and the resolutions were verified, which is what we did here, and it is the version we have published since.

What an audit does not buy you

Being direct about the limits, because we later learned some of them the hard way:

• It covers the code, not the design. A contract can be free of exploitable bugs and still behave badly under conditions nobody modelled.
• It is a snapshot. It applies to the version audited. Any change after that is unaudited until it is not.
• It cannot see the parts that are not code. Our single most damaging incident that year was not technical at all — it was a fraudulent listing agent, and no contract audit in existence would have caught it.

The clearest illustration is Q4 2022. The v2 contract's tax triggers malfunctioned under real market conditions and froze both the token and our liquidity pool. That was a design problem, not an unpatched bug, and it is why we eventually moved to plain standard ERC-20 tokenomics with nothing clever in the transfer path at all.

What we kept

The audit did its job. Holders were made whole through an automatic 1:1 airdrop, the hardened contract carried DHB through the following year, and the process became standard.

The larger lesson was cheaper to learn here than it would have been later: the audit is not the safety. The safety is the habit of assuming your contract is wrong until someone with no reason to be kind has tried to prove it.

How we talk about it

We do not use "audited" as a claim on its own, and we would encourage anyone assessing a project to treat the word as the beginning of a question rather than the end of one.

The useful questions are: audited by whom, against which version, what did they find, and what was actually changed as a result. A report with unresolved critical findings is still an audit. A report on a contract that has since been modified describes something no longer deployed.

Those questions are the reason the transparency reports and eventually dhbscan.com exist. They answer them without requiring anyone to ask.