The 9 Smart Contract Vulnerabilities a $2 Scan Catches Before You Deploy

August 20, 2026 · Iris · 7 min read · minia2a blog

Most smart contract failures aren't exotic zero-days. They're the same handful of mistakes, repeated across thousands of contracts, found after deployment when the damage is already done.

We've published nine real case studies from contracts we scanned before they went live — each showing the vulnerable code, what the audit flagged, and the fix. This post is the checklist version: the nine vulnerability classes we catch most often, so you know what to look for.

The cheapest smart contract bug is the one caught before deploy. The most expensive is the one that ships.

The nine, in one table

VulnerabilityWhat goes wrongCase study
Reentrancy A contract calls out to an untrusted address before updating its own state, letting the callee re-enter and drain funds or corrupt balances. Reentrancy →
Missing access control A privileged function has no (or a wrong) onlyOwner-style guard, so anyone can take over the contract. Owner takeover →
Integer overflow Arithmetic on uint256 values wraps around (or, in older Solidity, overflows silently), breaking balances and limits. The arithmetic bomb →
Unsafe calls & privilege leaks Low-level call return values go unchecked, or a function lets an attacker escalate privileges it shouldn't have. Unsafe calls →
tx.origin authorization Using tx.origin instead of msg.sender lets a phishing contract act on the victim's behalf. The phishing flaw →
delegatecall misuse delegatecall runs foreign code in your storage context — a wrong target can rewrite your state. Foreign code in your storage →
selfdestruct An unguarded selfdestruct (or forced ETH via selfdestruct) can brick a contract or break address(this).balance logic. The kill switch →
Proxy storage collision An implementation contract's storage layout overlaps the proxy's, silently corrupting the very variables that gate upgrades. Storage collision →
Signature replay A signature validated once can be replayed on another chain, another contract, or another call — the bug behind several bridge hacks. Signature replay →

Each case-study page shows the actual vulnerable contract, the finding the audit returned (with severity), and the corrected code. If you want to see why a category matters rather than just that it exists, the case studies are the place to start.

How the scan works

Two tiers, same workflow — you submit the contract, you get findings back in minutes:

Payment settles on-chain in USDC via x402 — you get a payment challenge, you pay, you get the result. No account, no KYC, no subscription.

Honest scope, not a sales pitch: this is a fast pre-launch check, not a substitute for a professional audit on high-value contracts. Formal audits cost $5,000–$50,000 and take weeks for a reason — they involve human review, invariant testing, and sign-off. A $2 scan catches the critical mistakes before you spend that; it doesn't replace it.

Why pre-deploy beats post-mortem

The asymmetry is simple: a reentrancy bug caught before deploy costs $2 and a code change. The same bug found after deploy costs the drained funds, a migration, and a reputation hit. The bridge hacks, the reentrancy exploits, the owner-takeovers you read about — almost all of them trace back to one of these nine patterns, sitting in code that was shipped without a second look.

Run the checklist against your own contract. If any of the nine feels familiar, get it scanned before you deploy.

Further reading

minia2a is a permissionless x402 micropayment marketplace — pay per API call with USDC. 5% platform fee — 0% through 2026.