The Hidden Code Problem: How Unverified Smart Contracts Are Becoming a Preferred Target for Attackers

Summary

• In the last six months, at least $36.7 million has been stolen from protocols whose source code was never publicly verified — meaning attackers had to decompile raw bytecode to find the vulnerabilities.
• The rise of AI-assisted exploit development is likely accelerating this trend, as large language models (LLMs) can now identify vulnerability patterns at scale.
• This is emerging as a distinct attack pattern. Although unverified contracts receive less public scrutiny, fewer community-driven bug reports, and are excluded from most bug bounty programs, they still hold millions in user funds.
• Real-time on-chain monitoring is especially critical for protocols deploying unverified contracts, since the traditional security ecosystem — white hat researchers, competitive audits, public code review — cannot function without readable source code.

A new pattern in crypto exploits

The crypto security community has long debated whether open-sourcing smart contract code makes protocols safer or simply provides attackers with a roadmap. In practice, the overwhelming majority of major DeFi protocols publish their source code and verify them on Etherscan, or other block explorers. But some protocols keep their code closed-source, denying would-be attackers (and also security researchers) an easy chance to analyze their code.

These hidden smart contracts aren’t immune from risks. Enterprising attackers just have to reverse-engineer them to figure out how they’ll break. And over the past six months, that’s exactly what’s been happening: attackers are increasingly targeting unverified, closed source smart contracts, in some cases exploiting years-old bugs for millions of dollars.

Attackers stole $36.7 million across four hacks of unverified smart contracts over the past six months, according to our analysis. This is a fraction of the more than $1 billion that DeFiLlama records being stolen from 88 protocols (most of them with verified smart contracts). But especially in the age where smart contracts can be easily decompiled, attacks against unverified contracts are likely to continue.

The data: $36.7 million from unverified contracts

We identified five protocols over the last six months where the exploited smart contract — not an attacker-deployed contract, but the protocol’s own code — was unverified on the relevant block explorer at the time of the exploit. Combined losses totaled approximately $36.7 million.

In each case, the protocol contract was unverified on Etherscan and had no published source code associated with it. The analysis focused solely on protocol-owned or protocol-deployed contracts responsible for holding, managing, or controlling user funds.

Case study: Truebit

On January 8, 2026, an attacker drained $26.2 million from Truebit, a tokenized asset protocol. The contract they targeted had been sitting on Ethereum since 2021, its implementation never verified on Etherscan.

The contract used a bonding curve mechanism where users could mint TRU tokens with ETH and burn them for ETH at a buyback rate. The vulnerability was an integer overflow in the getPurchasePrice() function. When called with extremely large input values, an unguarded addition operation (the contract was compiled with Solidity v0.5.3, which predates automatic overflow checks) wrapped around to near-zero. Effectively, the attacker could mint hundreds of millions of tokens for essentially nothing, then burn them for real ETH.

What makes this case especially striking is the on-chain evidence of systematic hunting. In the below Reactor graph we can see the same address that had drained the Sparkle protocol for 5 ETH just twelve days earlier. This was not an opportunistic find; the exploiter was methodically searching for vulnerabilities across verified and unverified contracts, escalating from small targets to a $26 million payday, and the proceeds of both exploits were laundered through Tornado Cash.

Why unverified contracts attract attackers

At first glance, it might seem counterintuitive that attackers would prefer closed-source targets. Decompiling EVM bytecode produces lower-quality output than reading raw Solidity, and the process requires specialized tooling and expertise.

But the trade-off favors attackers for several reasons:

1. AI-assisted decompilation and vulnerability analysis: The barrier to analyzing bytecode is falling rapidly. Modern decompilers like Dedaub, Heimdall, and Panoramix can produce readable Solidity from compiled bytecode. But the more significant shift is in what comes next: once decompiled, that code can be fed directly into LLMs for vulnerability analysis at scale and speed no human team can match. Researchers have demonstrated that LLMs can identify reentrancy flaws, access control gaps, and arithmetic errors in decompiled output with meaningful accuracy. When chained into automated pipelines, they can scan thousands of unverified contracts systematically, triaging targets by estimating exploitability and potential yield. What once required a skilled reverse engineer spending days on a single contract can now be partially automated across an entire blockchain’s unverified contract inventory. Attackers operating these pipelines gain a structural advantage: they can cover far more ground than the defenders monitoring for suspicious activity.
2. Less community scrutiny: Verified contracts benefit from an informal but powerful security layer: white hat researchers, competitive audit participants, and other developers who read the source code as part of their normal activity. Unverified contracts, however, receive none of this passive oversight. A vulnerability in a verified contract might be spotted by any of thousands of researchers; the same vulnerability in unverified bytecode is invisible to everyone except the deployer and anyone willing to decompile it.
3. Exclusion from bug bounties: Several of the exploited protocols in our dataset did have active bug bounty programs, but the unverified contracts were explicitly out of scope.

Implications and what protocols can do

The pattern we’ve identified carries specific implications for DeFi protocols, security teams, and the broader ecosystem:

Verify everything. Source code verification on block explorers should be treated as a minimum security requirement for any contract that holds or manages user funds. This includes implementation contracts behind proxies — several of the exploits in our dataset targeted unverified implementations hidden behind verified proxy shells.

Audit what you deploy, not just what you plan to deploy. Security reviews should cover the actual production deployment, including any contracts added between audit cycles.

Extend bug bounty coverage. If a contract holds user funds, it should be in scope for the bug bounty program regardless of whether it is on the “main” chain, a “legacy” product, or a recently added feature.

Implement real-time monitoring. For protocols deploying unverified contracts — whether intentionally or due to operational gaps — on-chain monitoring becomes the critical last line of defense. Tools like Chainalysis Hexagate can detect anomalous transaction patterns, flag suspicious function calls, and trigger automated responses even when the underlying source code is not publicly available. In an environment where exploits unfold in minutes or even blocks, real-time detection and automated pause capabilities are no longer optional.

Looking ahead

The convergence of three factors — a growing inventory of unverified contracts on public blockchains, increasingly capable decompilation tools, and AI models that can analyze bytecode at scale — suggests this trend will accelerate. Anthropic’s research has demonstrated that AI agents can autonomously achieve millions of dollars in successful exploits against previously compromised smart contracts, including contracts deployed after the models’ knowledge cutoff.

The smart contract threat does not exist in isolation. Across software security more broadly, AI-assisted exploitation is moving from theoretical concern to documented reality. A recent investigation by WIRED documented how automated tooling has enabled coordinated software supply chain attacks at scale on GitHub — the same pattern of systematic, pipeline-driven scanning that we are beginning to see applied to unverified on-chain bytecode. The underlying dynamic is the same: automation lowers the cost of finding vulnerabilities faster than it lowers the cost of defending against them.

Every unverified contract on Ethereum, Base, Arbitrum, BNB Chain, and other EVM networks is a potential target for automated scanning. The question is not whether attackers are building pipelines to systematically decompile and analyze these contracts — the on-chain evidence suggests they already are.

For DeFi protocols and their users, the message is straightforward: if your contract’s source code isn’t public, you’re relying on obscurity as a security measure — and that measure is rapidly losing its effectiveness.

Learn more about how Hexagate’s real-time on-chain threat detection can monitor smart contracts — including those without verified source code — and prevent exploits before funds are lost, or request a demo today.

This website contains links to third-party sites that are not under the control of Chainalysis, Inc. or its affiliates (collectively “Chainalysis”). Access to such information does not imply association with, endorsement of, approval of, or recommendation by Chainalysis of the site or its operators, and Chainalysis is not responsible for the products, services, or other content hosted therein. 

This material is for informational purposes only, and is not intended to provide legal, tax, financial, or investment advice. Recipients should consult their own advisors before making these types of decisions. Chainalysis has no responsibility or liability for any decision made or any other acts or omissions in connection with Recipient’s use of this material.

Chainalysis does not guarantee or warrant the accuracy, completeness, timeliness, suitability or validity of the information in this report and will not be responsible for any claim attributable to errors, omissions, or other inaccuracies of any part of such material.