Notifications
Clear all
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.
NHIMG editorial — based on content published by Chainalysis: AI-assisted attacks on unverified smart contracts and the losses they caused
By the numbers:
- Attackers stole $36.7 million across four hacks of unverified smart contracts over the past six months, according to Chainalysis.
- The more than $1 billion that DeFiLlama records being stolen from 88 protocols provides the broader loss context for this attack pattern, according to DeFiLlama.
Questions worth separating out
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 do unverified contracts attract attackers even though the code is harder to read?
A: They attract attackers because decompilation has become good enough to expose structure, and AI tools can then search the recovered code for exploitable patterns at scale.
Q: How can teams know if an unverified contract is operating outside its intended boundary?
A: Teams should monitor for unexpected function calls, unusual token movement, and changes in transaction patterns that do not match normal protocol behaviour.
Practitioner guidance
- Require source verification for every fund-holding deployment Block production release unless the deployed bytecode can be matched to readable source code on the relevant block explorer, including implementation contracts behind proxies.
- Expand audit scope to the live implementation Review the exact contract that runs in production, not just the intended design, and re-check any implementation added after the last audit cycle.
- Put unverified contracts into bug bounty scope Include any contract that can move or custody user funds, even if it is legacy code or a recently added feature outside the original bounty boundary.
What's in the full report
Chainalysis' full analysis covers the operational detail this post intentionally leaves for the source:
- A protocol-by-protocol breakdown of the four unverified-contract exploits and the vulnerable functions involved.
- The bytecode-to-decompilation workflow attackers use to identify reentrancy, access control, and arithmetic flaws.
- The monitoring and pause-control approaches Chainalysis says can detect suspicious on-chain behaviour before funds are lost.
- The implications of proxy patterns where a verified shell can hide an unverified implementation.
👉 Read Chainalysis' analysis of AI-assisted attacks on unverified smart contracts →
Unverified smart contracts: what the governance gap means now?
Explore further
10/07/2026 9:47 pm
Unverified contract governance is a trust problem, not a visibility preference. When deployed logic cannot be independently inspected, the protocol is asking users to trust hidden execution paths while also expecting defenders to catch problems after the fact. That model weakens the review ecosystem that verified contracts depend on. The practical conclusion is that unverifiable production code should be treated as a governance exception, not an acceptable normal state.
A question worth separating out:
Q: Who is accountable when a hidden contract is exploited and user funds are lost?
A: Accountability sits with the protocol operator, because deploying opaque production code does not remove the duty to verify what was shipped and to monitor it continuously. Security, engineering, and governance leaders should treat source verification and runtime monitoring as owned controls, not optional safeguards.
👉 Read our full editorial: AI-assisted attacks on unverified smart contracts are accelerating
