Topic starter
10/07/2026 9:25 pm
TL;DR: Attackers stole $36.7 million from unverified smart contracts in the past six months, with decompiled bytecode and AI-assisted analysis making closed-source contracts easier to target while bypassing the scrutiny that verified code receives, according to Chainalysis. Obscurity is no longer a defensible control when exploit discovery is becoming pipeline-driven and faster than manual review.
Editorial analysis by NHI Mgmt Group, based on content published by Chainalysis: “The Hidden Code Problem: How Unverified Smart Contracts Are Becoming a Preferred Target for Attackers”.
By the numbers:
- Attackers stole $36.7 million across four hacks of unverified smart contracts over the past six months, according to Chainalysis.
Key questions
Q: What breaks when smart contracts are deployed without verified source code?
A: When source code is not verified, defenders lose the broad review surface that catches logic errors before attackers do.
Q: Why does AI-assisted analysis increase the risk of unverified contracts?
A: AI reduces the time needed to turn decompiled bytecode into a ranked list of likely weaknesses.
Q: How can teams tell whether an unverified contract is becoming a target?
A: Look for suspicious transaction clustering, unusual function-call sequences, repeated probing of edge-case inputs, and rapid movement from low-value tests to larger-value exploits.
Practitioner guidance
- Verify every production contract that holds funds Make source verification mandatory for deployed contracts, including proxy implementations and legacy components that were added after audit completion.
- Extend bug bounty scope to deployed logic Ensure any contract that can move, mint, or lock funds remains in scope even if it is behind a verified shell or considered non-core.
- Monitor unverified contracts in real time Use on-chain anomaly detection and automated pause controls to catch suspicious function calls, unusual transaction patterns, and rapid exploit sequences.
Bottom line: Unverified smart contracts create a control gap because they remove public review, weaken bounty coverage, and leave production logic harder for defenders to inspect.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
10/07/2026 9:47 pm
Unverified code is now a governance failure, not just a transparency choice: when a contract controls user funds, keeping the source closed removes the review ecosystem that normally acts as a control layer. Security teams should treat verification as part of production governance, not a cosmetic publication decision. The practical consequence is that obscurity shifts risk onto runtime controls that are slower and weaker than pre-deployment review.
A few things that frame the scale:
- Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: Should bug bounty scope include contracts that are not publicly verified?
A: Yes, if the contract can hold, move, mint, or lock user funds. Excluding unverified logic from bounty scope creates a coverage gap exactly where attackers may concentrate effort. A bounty programme is only meaningful when it follows the deployed control point, not the organisation’s preferred architecture diagram.
👉 Read our full editorial: AI-assisted attacks on unverified smart contracts are accelerating