# Smart contract security checklist before you launch (2026)

*By Roberto Lazar, founder of Dock30 · Published 2026-06-13 · Updated 2026-07-25 · 7 min read*

A 12-point pre-launch security checklist for smart contracts, with the 2025 loss data, current tooling, and what an audit actually costs in 2026.

Before you deploy a smart contract to mainnet, verify twelve things: access control, reentrancy protection, input validation, safe external calls, oracle integrity, arithmetic safety, upgradeability controls, gas and DoS limits, event logging, test coverage, static analysis in CI, and an independent audit for anything holding real value. The order matters. The largest crypto losses of 2025 came from stolen keys and misconfigured permissions, not exotic contract exploits, so the unglamorous items at the top of the list prevent the most damage.

Web3 launches are where Dock30 started in 2021, and every contract we ship still goes through the same gauntlet before a token generation event or mint. This article is that gauntlet written down: the Dock30 12-point pre-launch contract check, updated for what 2025 taught the whole industry the hard way.

## What the 2025 loss data actually says

Attackers took about **$3.35 billion** from Web3 platforms in 2025, up roughly 55% year over year, and the top three incidents alone accounted for 69% of all losses, per the [Chainalysis 2026 Crypto Crime Report](https://www.chainalysis.com/blog/2026-crypto-crime-report-introduction/). The biggest of those was Bybit in February 2025: around **$1.5 billion**, the largest crypto theft ever recorded. It was executed through compromised signing infrastructure, not a contract bug. The attackers manipulated what the signers thought they were approving, and the signers approved it.

Hacken's breakdown makes the pattern explicit. Their [2025 security report](https://hacken.io/insights/2025-security-report/) attributes about **$1.83 billion** of the year's losses to access-control failures, and puts access control plus operational security together at roughly 54% of everything stolen. Losses from genuine smart contract bugs came to about $512 million. Half a billion dollars is still worth defending against, which is why the code-level checks below stay on the list. But if your admin key lives on one laptop, your Solidity is not the weakest link. You are.

## The Dock30 12-point pre-launch contract check

| # | Check | What you're verifying |
|---|---|---|
| 1 | Access control | Every privileged function is gated with the right modifier and role checks |
| 2 | Reentrancy | State changes before external calls (CEI), plus a reentrancy guard where value moves |
| 3 | Input validation | External inputs bounds-checked, zero-address guards in place |
| 4 | External calls | Return values checked, no blind `call` without failure handling |
| 5 | Oracle integrity | Staleness checks, sanity bounds, no single manipulable price source |
| 6 | Arithmetic | Overflow-safe, rounding direction intentional, `unchecked` blocks justified |
| 7 | Upgradeability | Proxy admin behind a multisig, storage layout preserved across upgrades |
| 8 | Gas and DoS | No unbounded loops over user-controlled arrays |
| 9 | Event logging | Every state-changing action emits an event for off-chain monitoring |
| 10 | Test coverage | Above 95% line and branch coverage, including failure paths (our house bar) |
| 11 | Static analysis | Slither and Aderyn in CI with zero unresolved high findings |
| 12 | Third-party audit | Independent review for any contract holding meaningful value |

Items one through nine are code review. Ten through twelve are process. Teams under launch pressure always cut the process half first, and the process half is where the machine catches what tired reviewers miss.

## Access control and key management

Most large on-chain losses trace back to a privileged function anyone could call, or an admin key that was never properly secured. Before launch:

- Confirm every `onlyOwner` and role-gated function is actually gated, and that the modifier is applied rather than merely defined. In our reviews, the most common finding is not a missing check but a check against the wrong role.
- Use OpenZeppelin's `AccessControl` or `Ownable2Step`, both current in Contracts 5.x, instead of hand-rolled checks. `Ownable2Step` exists because a mistyped address in a one-step ownership transfer bricks the contract permanently.
- Put mainnet keys with mint, pause, or upgrade rights behind a multisig, ideally with a timelock. A single EOA holding those rights is one phishing email away from total loss.
- Treat signing infrastructure as attack surface. The Bybit signers had a multisig and still lost $1.5 billion because the UI lied to them. Verify transaction details on the hardware wallet screen, every time.

## Reentrancy in 2026, beyond the classic case

Reentrancy is older than most DeFi protocols and still draining them, because the modern variants are subtler than the 2016 textbook example:

- Cross-function reentrancy, where the attacker re-enters through a different function that shares state with the one mid-execution.
- Cross-contract reentrancy, where the callback touches a second contract that trusts stale state from the first.
- Read-only reentrancy, where a `view` function returns manipulated state mid-transaction and an integrator's logic consumes it.

The defense has not changed: follow Checks-Effects-Interactions, so state updates land before any external call, and add `nonReentrant` to functions that move value.

```solidity
// OpenZeppelin Contracts 5.x: ReentrancyGuard moved to utils/
import {ReentrancyGuard} from "@openzeppelin/contracts/utils/ReentrancyGuard.sol";

contract Vault is ReentrancyGuard {
    mapping(address => uint256) public balances;

    function withdraw(uint256 amount) external nonReentrant {
        require(balances[msg.sender] >= amount, "insufficient"); // checks
        balances[msg.sender] -= amount;                          // effects
        (bool ok, ) = msg.sender.call{value: amount}("");        // interactions
        require(ok, "transfer failed");
    }
}
```

Note the import path. In Contracts 5.x, `ReentrancyGuard` lives under `utils/`, not the old `security/` folder, and there is a newer `ReentrancyGuardTransient` that uses EIP-1153 transient storage for a cheaper guard on chains that support it, per the [OpenZeppelin 5.x docs](https://docs.openzeppelin.com/contracts/5.x/api/utils). If your imports still point at `security/`, you are on 4.x patterns and should check what else drifted.

## Arithmetic, oracles, and external calls

Solidity 0.8+ reverts on overflow by default, which retired a whole class of bugs, but `unchecked` blocks opt back out of that protection and rounding never went away. In share and price math, make the rounding direction a deliberate decision that favors the protocol, and write a test asserting it. We have seen a vault leak value one wei at a time because deposits rounded one way and withdrawals rounded the same way.

For oracles, never trust a single spot price. Validate freshness with staleness checks, sanity-bound the values, and prefer time-weighted or multi-source feeds for anything that gates value. A lending protocol reading one DEX pool's spot price is an invitation with a flash loan attached.

Treat every external call as hostile. Check return values, avoid forwarding all remaining gas blindly, and assume the callee can call you back before the current function finishes.

## Tooling and CI gates (and what happened to MythX)

If a security checklist you are reading recommends MythX, it is out of date. The earlier version of this article did too. [MythX was sunset by Consensys](https://mythx.io/sunset/), so here is the stack we actually run in 2026:

- Slither on every push, with the build failing on high-severity findings. Still the workhorse.
- Aderyn as a second static analyzer. It is Rust-based, fast enough for CI, and flags a somewhat different set of issues than Slither, which is exactly what you want from a second opinion.
- Mythril for symbolic execution. It is the open-source engine MythX was built on and it is still maintained. It runs slowly, so we schedule it nightly and before releases rather than on every commit.
- Foundry fuzz and invariant tests for the properties you cannot enumerate by hand: total supply conservation, solvency, access invariants. Echidna is worth adding as a second fuzzer because its corpus strategy differs from Foundry's.
- A coverage gate above 95% line and branch, revert paths included. To be clear, that number is our house bar rather than an industry benchmark. The revert paths are the part that matters; happy-path coverage is easy and proves little.

All of it lives in CI, so a contract cannot reach deployment without passing. It is the same release discipline we apply across our [blockchain and Web3 work](/services/blockchain-web3), and honestly the same discipline any backend deserves.

## What an audit costs in 2026, and when you can skip it

Audit pricing has settled enough to be citable. Per [QuillAudits](https://www.quillaudits.com/blog/smart-contract/smart-contract-audit-cost-2026) and [Sherlock's 2026 market reference](https://sherlock.xyz/post/smart-contract-audit-pricing-a-market-reference-for-2026):

| Scope | Typical 2026 price |
|---|---|
| Basic token audit (ERC-20, simple logic) | $5,000 to $15,000 |
| Standard pre-launch DeFi review | $15,000 to $40,000 |
| Complex protocol (lending, cross-chain, novel AMM) | $100,000 to $300,000+ |

You do not always need one. A stock OpenZeppelin ERC-20 with no custom transfer, fee, or mint logic gets little marginal safety from a $15k audit; run the tooling, get an experienced reviewer for a day, and spend the savings on securing your keys, which is where the real 2025 losses came from anyway. The calculus flips the moment the contract holds user funds or contains custom value flows. Then the audit is a small fraction of what is at stake, and it belongs on the calendar weeks before launch, because auditors will find things and you need time to fix and retest them before mainnet, not after.

One more opinion from experience: an audit is a snapshot, and a diff after the audit invalidates it. Freeze scope before the review starts, and if you must change something afterward, get the delta re-reviewed. Plenty of exploited protocols had a clean audit of code they no longer ran.

We have been shipping Web3 launches since 2021, and this checklist is how we gate ours. If you have a contract heading to mainnet and want a second set of eyes before it holds real money, we run this exact review as a [fixed-scope project](/pricing/project) with the price and delivery date in writing before we start. Book a [free 15-minute call](https://calendly.com/dock30/15min) or send the repo through our [contact page](/contact), and we will tell you straight whether you need us or just a weekend with Slither.

## Frequently asked questions

**What should I check before deploying a smart contract?**

Verify access control, reentrancy protection, input validation, safe external calls, oracle integrity, and arithmetic safety in the code itself. Then gate the release on high test coverage, static analysis in CI, and an independent audit if the contract will hold real value. Key management matters as much as the code, so put admin rights behind a multisig before mainnet.

**What causes the biggest smart contract losses?**

Access-control and key failures, not exotic code exploits. Hacken attributes about $1.83 billion of 2025 losses to access-control failures, while losses from genuine smart contract bugs were around $512 million. The Bybit theft of roughly $1.5 billion went through compromised signing infrastructure rather than a contract bug.

**How much does a smart contract audit cost in 2026?**

A basic token audit runs about $5,000 to $15,000, a standard pre-launch DeFi review $15,000 to $40,000, and complex protocols $100,000 to $300,000 or more. Price scales with code size, novelty, and how much value the contract will hold at launch.

**Is MythX still available?**

No. MythX was shut down by Consensys, so any pipeline or checklist that still lists it is out of date. Mythril, the open-source symbolic execution engine MythX was built on, is still maintained. Most teams now pair it with Slither, Aderyn, and fuzzing through Foundry or Echidna.

**Do I need an audit for a simple ERC-20 token?**

If it is a stock OpenZeppelin ERC-20 with no custom transfer, fee, or mint logic, static analysis plus an experienced independent review is usually defensible. The moment you add custom value flows or the token backs a protocol holding user funds, budget for a full audit and schedule it weeks before launch, since remediations take time to implement and retest.

---

Written by Roberto Lazar, founder of Dock30. Book a call: https://dock30.com/contact