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.
At a glance
What this is: Chainalysis says unverified smart contracts are being targeted as AI-assisted tooling lowers the cost of decompiling bytecode and spotting exploitable flaws.
Why it matters: For DeFi and broader Web3 governance, this shows that source code verification, bug bounty scope, and real-time monitoring are now core control decisions, not optional hardening steps.
By the numbers:
- Attackers stole $36.7 million across four hacks of unverified smart contracts over the past six months, according to Chainalysis.
Context
Unverified smart contracts create a governance gap because defenders lose the benefits of public review, community scrutiny, and normal bug bounty coverage while the contract still controls user funds. In practice, the risk is not just code secrecy, but the absence of the ecosystem controls that usually surface defects before attackers do.
This matters for identity and access governance as much as it does for application security because smart contracts act like autonomous control points over assets, permissions, and transaction logic. When source code is hidden, security teams lose a basic verification layer and must rely more heavily on runtime monitoring, scope control, and deployment discipline.
The article’s examples show that closed-source does not mean low-risk. In this case, obscurity reduced defender visibility but did not reduce attacker incentive or capability.
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. The contract can still be analysed through bytecode, but the hidden implementation reduces transparency, limits bug bounty coverage, and shifts security from prevention to detection after deployment.
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. That matters because attackers can inspect more contracts, more quickly, and focus on those with the highest potential payout. The risk is not that AI invents new flaws, but that it industrialises discovery across contracts defenders already struggle to review.
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. Those behaviours suggest systematic scanning rather than a one-off event. In practice, telemetry and alerting need to focus on behavioural anomalies because source-based review is unavailable.
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.
Technical breakdown
Why unverified smart contracts are easier to attack than they look
A smart contract that is not publicly verified still exists as readable bytecode on-chain, which means attackers can decompile it even if defenders cannot easily review it. The difference is that defenders lose the informal security layer created by open source review, audit reuse, and community detection of edge cases. Once bytecode is converted into approximate Solidity, AI models can help identify arithmetic mistakes, access-control gaps, and unsafe assumptions at scale. That shifts discovery from manual reverse engineering to pipeline-driven triage, which is much faster and broader.
Practical implication: Treat source code verification as a baseline control for any contract that holds or controls funds.
How AI-assisted analysis changes exploit discovery
Large language models do not need perfect source code to be useful to an attacker. They can analyse decompiled output, compare patterns across many contracts, and prioritise targets by likely exploitability and payout. That means the attack surface is no longer limited by human time or skill in the same way it once was. In effect, AI compresses the effort needed to move from bytecode to a ranked list of candidate flaws, especially where the same programming mistakes repeat across protocols and deployment cycles.
Practical implication: Assume vulnerability discovery may be automated and faster than audit cadence, so monitor production deployments continuously.
Why runtime monitoring becomes a compensating control
When source code is unavailable, the normal pre-deployment review stack weakens, but the contract still emits observable on-chain behaviour. That makes transaction-pattern monitoring, function-call anomaly detection, and automated pause logic the main remaining control layer. Runtime monitoring does not replace verification, but it can shorten the time between exploit initiation and containment. For protocols with unverified implementations behind verified proxy shells, this becomes especially important because the visible shell can mask an unreviewed execution path.
Practical implication: Put unverified or partially verified contracts under continuous on-chain detection and automated response controls.
Threat narrative
Attacker objective: The objective was to find unverified contracts with exploitable logic and convert bytecode analysis into direct theft from protocol-held funds.
- Entry occurred through public-chain bytecode inspection and decompilation of an unverified protocol contract, which revealed attackable logic without needing published source code.
- Attackers used AI-assisted analysis and tooling to identify exploitable patterns such as arithmetic errors, access-control flaws, and validation bypasses across candidate contracts.
- Exploitation led to direct theft of protocol funds, with the Truebit case showing how an integer overflow could be abused to mint tokens cheaply and drain ETH.
- Impact included multi-million-dollar losses and laundering of proceeds through privacy tooling, while the broader pattern signalled a scalable exploit pipeline against closed-source DeFi deployments.
Breaches seen in the wild
- Samsung ChatGPT leak 2023: Samsung staff pasted chip source code and meeting notes into ChatGPT weeks after it was allowed, leading Samsung to restrict generative AI tools.
- Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Secret sprawl has a close analogue in contract secrecy: hidden production logic creates blind spots that defenders cannot inventory, review, or scope properly. In identity terms, this is a trust-boundary problem because the contract’s authority over funds persists even when its implementation is opaque. Practitioners should assume that unverifiable logic will eventually be targeted, not merely inspected.
AI does not create the flaw, but it industrialises discovery: decompilation plus LLM-assisted reasoning turns what used to be artisanal reverse engineering into scalable target selection. That changes the attacker economics more than the vulnerability class itself. The field should therefore focus less on whether secrecy slows attackers and more on how fast exploit pipelines can rank and test likely weaknesses.
AI-assisted attack pipelines are becoming a threat pattern in their own right: the article’s central signal is not simply that attackers used AI, but that AI can chain decompilation, pattern recognition, and exploit triage into an operational workflow. That is a meaningful shift for governance because it compresses the time between code exposure and monetisation. The practical conclusion is that detection and pause mechanisms must assume machine-speed adversaries.
For DeFi teams, scope control matters as much as code quality: the article shows that contracts left out of bug bounty scope or hidden behind verified proxies can still be the actual point of failure. The governance gap is not just unsafe logic, but incomplete operational coverage. Security owners should align verification, bounty scope, and monitoring to the deployed contract, not the intended architecture.
From our research library:
- 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.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Unverified production logic is a governance blind spot: the problem is not just that code is hidden, but that the surrounding ecosystem cannot perform the review, bounty, and assurance functions that verified contracts normally receive. For DeFi teams, that means deployment governance has to include verification status as a live control, not a post-release formality.
AI-assisted exploit pipelines will narrow the defender window: once bytecode can be decompiled and triaged at scale, the main security variable becomes how quickly teams can detect abnormal behaviour and pause execution. According to the State of Secrets Sprawl 2026, AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
On-chain monitoring is now a compensating control for opaque deployments: when verification is missing, transaction-pattern analytics, alerting, and automated response become the last practical line of defence. Teams should watch for the first signs of systematic probing, because once attack pipelines are established, exploit volume can rise faster than manual review capacity.
For practitioners
- 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.
- Audit the deployed artifact, not just the planned release Compare the audited design against the exact contract address and bytecode in production so post-audit changes do not create blind spots.
Key takeaways
- Unverified smart contracts create a control gap because they remove public review, weaken bounty coverage, and leave production logic harder for defenders to inspect.
- Chainalysis says attackers stole at least $36.7 million from unverified contracts in six months, showing that hidden code does not reduce attacker interest.
- Protocols that cannot verify source code need stronger runtime monitoring, stricter deployment governance, and tighter scope around the exact contracts that hold user funds.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006; TA0010 — Credential Access; Exfiltration | The article describes adversarial discovery and monetisation flows against contract logic. |
| Recommendation — Map exploit chains to TA0006 and TA0010 to prioritise detection of scanning and fund-drain behaviour. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-Rest Protection | Contract-held funds and related control logic require strong protection of the asset state. |
| Recommendation — Apply PR.DS-01 to preserve the integrity of funds and contract state under adversarial analysis. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The attack pattern centres on weaknesses in deployed application logic. |
| Recommendation — Use CIS-16 to verify production contract logic, not just intended design, before release. | ||
| OWASP API Security Top 10 | API6 — Unrestricted Access to Sensitive Business Flows | Attacks abuse contract workflows that move or mint assets. |
| Recommendation — Treat sensitive asset-moving contract flows as high-risk business logic and monitor them for abuse. | ||
Key terms
- Unverified Smart Contract: A smart contract whose source code has not been publicly verified against the deployed bytecode on a block explorer. Without that verification, independent reviewers cannot inspect the exact logic running in production, which weakens pre-deployment scrutiny and shifts reliance toward runtime monitoring and post-incident analysis.
- Bytecode Decompilation: The process of converting compiled blockchain bytecode back into a readable approximation of source logic. Decompilation is imperfect, but it can reveal function structure, storage behaviour, and suspicious patterns closely enough for attackers or defenders to analyse risk at scale.
- On-Chain Monitoring: On-chain monitoring is the process of observing blockchain transactions and related activity for risk, compliance, or operational signals. In regulated environments, it must be linked to internal records and escalation workflows so teams can investigate activity, not just observe it.
- Runtime control: Controls that enforce policy while an AI system is operating, rather than after the fact. For healthcare chatbots, runtime control includes data masking, output filtering, access scoping, and immutable logging so the organisation can defend the interaction itself.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity for practitioners who need to connect access control to operational risk. It helps security and identity teams strengthen governance across human and non-human systems alike.
Published by the NHIMG editorial team on July 10, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org