Before deploying a smart contract to mainnet in 2026, verify these 12 items: access control, reentrancy protection, input validation, safe external calls, oracle integrity, arithmetic safety, upgradeability controls, gas/DoS limits, event logging, test coverage above 95%, static analysis in CI, and a third-party audit for anything holding real value. Access-control failures, not exotic exploits, are behind the largest losses — so the boring items at the top matter most.
We run every contract through the same gauntlet before a token generation event or mint. This is that gauntlet, written down: the Dock30 12-Point Pre-Launch Contract Check.
The Dock30 12-point pre-launch contract check
| # | Check | What you're verifying |
|---|---|---|
| 1 | Access control | Every privileged function has the right modifier and owner/role checks |
| 2 | Reentrancy | State changes before external calls (CEI); ReentrancyGuard where needed |
| 3 | Input validation | All external inputs bounds-checked; zero-address guards in place |
| 4 | External calls | Return values checked; no blind call without handling failure |
| 5 | Oracle integrity | Price feeds validated, staleness checks, no single manipulable source |
| 6 | Arithmetic | Overflow/underflow safe; rounding direction intentional |
| 7 | Upgradeability | Proxy admin keys secured; storage layout preserved across upgrades |
| 8 | Gas & DoS | No unbounded loops over user-controlled arrays |
| 9 | Event logging | State-changing actions emit events for off-chain monitoring |
| 10 | Test coverage | >95% line and branch coverage, including failure paths |
| 11 | Static analysis | Slither / MythX run in CI with zero unresolved high findings |
| 12 | Third-party audit | Independent audit for any contract holding meaningful value |
Access control & privilege — the #1 loss vector
Most large on-chain losses don't come from clever cryptographic attacks. They come from a privileged function that anyone could call, or admin keys that were never secured. Before launch:
- Confirm every
onlyOwner/ role-gated function is actually gated, and that the modifier is applied — not just defined. - Use a battle-tested access pattern (OpenZeppelin
AccessControl/Ownable2Step) rather than hand-rolled checks. - Move mainnet admin keys behind a multisig. A single EOA holding upgrade or mint rights is a single point of catastrophic failure.
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 example:
- Cross-function reentrancy — an attacker re-enters through a different function that shares state.
- Cross-contract reentrancy — the callback touches a second contract that trusts stale state.
- Read-only reentrancy — a view function returns manipulated state mid-transaction, corrupting an integrator's logic.
The defense is unchanged and non-negotiable: follow Checks-Effects-Interactions — update state before making external calls — and add a nonReentrant guard on functions that move value.
Arithmetic, oracle & external-call risks
- Arithmetic. Solidity 0.8+ reverts on overflow, but rounding and unchecked blocks still bite. Make rounding direction a deliberate decision, especially in share/price math.
- Oracles. Never trust a single spot price. Validate freshness, sanity-bound values, and prefer time-weighted or multi-source feeds for anything that gates value.
- External calls. Treat every external call as hostile. Check return values, avoid passing all remaining gas blindly, and assume the callee can call you back.
Tooling & CI gates
Manual review doesn't scale and humans miss things. Make the machine check first:
- Static analysis — run Slither (and MythX for symbolic analysis) on every push. Fail the build on high-severity findings.
- Fuzzing — use Foundry's property-based fuzzing to probe invariants you can't enumerate by hand.
- Coverage gates — require >95% coverage including revert paths, not just the happy path.
All of this lives in CI, so a contract literally cannot be deployed without passing. It's the same release discipline we apply across our blockchain work.
When to get a third-party audit
Internal review and tooling catch most issues, but anything holding real user funds warrants independent eyes. A focused audit for a standard token or staking contract is a worthwhile fraction of what's at stake; budget for it, schedule it before your launch date (not the week of), and implement every remediation before mainnet.
Frequently asked questions
What should I check before deploying a smart contract? At minimum: access control, reentrancy protection, input validation, safe external calls, oracle integrity, arithmetic safety, and full test coverage — plus static analysis in CI and a third-party audit for value-holding contracts.
What is the most common smart contract vulnerability in 2026? Access-control failures — missing or misapplied permission checks and unsecured admin keys — account for the largest share of losses, ahead of reentrancy.
Do I really need a third-party audit? For any contract holding meaningful value, yes. Internal review and tooling reduce risk but an independent audit catches issues your team is blind to.
What tools should run in CI? Slither for static analysis, MythX for symbolic checks, Foundry for fuzzing, and a coverage tool gating at >95% — all configured to fail the build on high-severity findings.
Launching a token or dApp? Our blockchain team runs this exact pre-launch review. Book a call for an audit-ready contract.