Smart Contract Audit Before Token Launch: What to Check

A smart contract audit is an independent security review of a project’s code before real money depends on it. It reduces the odds of obvious bugs but never proves safety. The useful questions are who audited, what was in scope, what was found, and whether the fixes were verified.

What an audit actually covers

Auditors read the contract code, run tools, write extra tests and look for classic flaws such as reentrancy, bad access control, arithmetic errors and price-manipulation exposure. They deliver a report listing findings by severity, and the team responds by fixing, acknowledging or disputing each one. A good report shows the code version audited, so you can match it against what was deployed.

Self-testing versus an audit

Projects often run their own tests, and those are worth reading. They are not independent. The Bitcoin.one whitepaper reports 31 Foundry tests, including fuzz tests, LiteSVM tests for its Solana program and a Slither run with no actionable findings. It also uses OpenZeppelin libraries and Solidity 0.8.24, and Ownable2Step for admin contracts. Those are sensible practices, and they come from the team itself.

Evidence	Independent?	What it tells you
Unit and fuzz tests	No	The team checked its own assumptions
Static analysis (Slither)	No	No common patterns flagged by a tool
External audit	Yes	Specialists reviewed a defined scope
Public bug bounty	Partly	Ongoing incentive for outside review
Time live with real value	Yes	Survival under real attack

What the paper says about its audit

The paper says an external audit is planned before the token generation event and that the report will be published. Its own known-limitations list says the contracts are not externally audited, and the risk disclosure says the same. The paper does not name the audit firm, scope or completion date. Until a report exists, the accurate description is “planned”. That matters for anyone considering the presale, because presale payments happen before the audit is complete, according to the paper’s timeline.

Key takeaway: treat an announced audit as a future event. Weight your decision on the published report, not the announcement.

How to read an audit report

1. Auditor reputation. Is the firm known, and does it publish its work under its own name?
2. Scope. Which contracts, which commit hash? Excluded contracts are unreviewed. For Bitcoin.one that list would include presale, claim, vesting, PayRouter, CheckoutRouter, BuybackVault and staking contracts.
3. Findings by severity. Critical and high issues should be fixed, not just acknowledged.
4. Re-review. Was the fixed code checked again?
5. Match to deployment. Compare the audited version with the deployed bytecode.
6. Out-of-scope risks. Oracles, bridges, off-chain keepers and front ends.

Risks no audit removes

The paper’s own limitations show where audits stop. It lists exposure to Uniswap pool and price manipulation, failure of off-chain components (indexer, keeper, Bitrefill and email) and the fact that NOWPayments entitlements rely on a database until committed to the Merkle root. Those are system risks, not code defects in a single contract. See how they interact in the presale risk checklist.

Admin power is another. The paper says owners can change fee settings within ceilings and the burn share, with events emitted on each change, and that the keeper is a hot key with contract-limited powers. An audit can confirm the ceilings are enforced in code; it cannot judge whether people with owner keys behave well.

Timing: why “before launch” matters

Fixing a bug before launch costs time. Fixing it after launch can cost user funds. If a project accepts money before an audit is finished, the buyer carries extra risk during that window. Some projects delay sales until the report is out; others do not. Neither approach is a guarantee.

What you can verify yourself

• Contract addresses and verified source on a block explorer.
• Presence of admin functions such as pause, mint or upgrade.
• Whether the vesting contract is immutable, as described in token vesting schedules explained.
• On-chain activity on the project’s buybacks page, once mainnet exists.

A fair conclusion

A planned audit, public tests, hardware-held keys and capped fees are all positive signs on paper. They do not substitute for a published, independent report and some time live. Read the paper alongside our whitepaper reading method, keep exposure small, and re-check when the audit is published. This is not investment advice.

Questions to put to any team

If you can contact a project, a short list of questions often tells you more than the report itself:

1. Which firm are you using, and can you share the engagement scope?
2. Will you publish the full report, including unresolved findings?
3. Will launch wait for the audit, or will sales proceed first?
4. Is there a bug bounty after launch?
5. Who holds the admin keys, and are they hardware-protected or multisig?

The Bitcoin.one paper answers parts of the last question: treasury and owner keys on Ledger hardware, and a keeper that is a hot key with contract-limited powers. It does not answer the first three yet. That is the status as of this writing, and a good reason to check back.

Differences between audits and formal verification

Audits are human-led reviews. Formal verification proves specific properties mathematically for a defined model. Some projects use both, and most use neither. The paper mentions fuzz tests, which sit between unit tests and formal proofs: they throw many random inputs at the code to find unexpected behaviour. That is helpful, but it checks the properties the developers thought to write.

Method	What it finds	Limits
Unit tests	Expected behaviour regressions	Only what was written
Fuzzing	Unexpected inputs breaking invariants	Needs good invariants
Static analysis	Known bad patterns	False negatives
Manual audit	Logic and design flaws	Time-boxed, scope-limited
Formal verification	Proven properties	Costly, narrow

After the report

Read the final report for unresolved issues and for any change in code after the audit. A report dated months before deployment may not cover later edits. Compare the audited commit with what is deployed, and re-check when the project upgrades contracts. Note that the buybacks page and other dashboards will only show real on-chain data after mainnet, which is the stage where an audit’s value is tested.